Dark Mode

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings
This repository was archived by the owner on May 7, 2020. It is now read-only.

stoveproject/Stove

Repository files navigation

Stove

Package Status
Stove
Stove.Entityframework
Stove.EntityframeworkCore
Stove.Hangfire
Stove.NLog
Stove.Serilog
Stove.Mapster
Stove.Redis
Stove.Dapper
Stove.RabbitMQ
Stove.NHibernate
Stove.RavenDB
Stove.Couchbase

Stove is an application framework that wraps and abstracts your needs for easy use. Built with strongly adopted dependency injection principles.

IoC

Use-Case & Transaction approach

  • AsyncLocal Unit Of Work pattern

Adopted principles

  • Domain Driven Design
  • Persistence agnosticism with IRepository
  • EventBus for DDD use cases

Persistence Support

  • EntityFramework
  • EntityFramework Core
  • NHibernate

Transactional structure

Tool Supports Multiple Database/Session Control inside one UOW
EntityFramework
EntityFrameworkCore
NHibernate
Dapper

Notes

  • To work with Dapper, you must use EF & EF Core or NHibernate as primary ORM choice. Dapper shares their transactions to execute its sqls inside of one Unit Of Work scope.

  • Dapper-EntityFramework, Dapper-NHibernate or Dapper-EntityFrameworkCore works under same transaction and unit of work scope, if any exception appears in domain whole transaction will be rollback, including Dapper's insert/deletes or EF's or NH's.

  • Stove.Dapper supports Dynamic Filters to filter automatically and default ISoftDelete or other user defined filters.

  • NHibernate supports multiple database in one UOW scope.

Nhibernate Multiple Database

Let's assume that we have two entities which are inherited from Entity. If we want to work with multiple database with NHibernate we have to tell to Stove that which entities belong to which database or session. To achive that Stove has to know your database distinction. Basically StoveSessionContext does that.

StoveSessionContext

public class PrimaryStoveSessionContext : StoveSessionContext
{
public IStoveSessionSet<Product> Products { get; set; }
}
public class SecondaryStoveSessionContext : StoveSessionContext
{
public IStoveSessionSet<Category> Categories { get; set; }
}

Registration:

builder
.UseStoveNHibernate(nhConfiguration =>
{
nhConfiguration.AddFluentConfigurationFor<PrimaryStoveSessionContext>(() =>
{
return Fluently.Configure()
.Database(SQLiteConfiguration.Standard.InMemory())
.Mappings(m => m.FluentMappings.AddFromAssembly(Assembly.GetExecutingAssembly()))
.ExposeConfiguration(cfg => new SchemaExport(cfg).Execute(true, true, false, _connection, Console.Out));
});

nhConfiguration.AddFluentConfigurationFor<SecondaryStoveSessionContext>(() =>
{
return Fluently.Configure()
.Database(SQLiteConfiguration.Standard.InMemory())
.Mappings(m => m.FluentMappings.AddFromAssembly(Assembly.GetExecutingAssembly()))
.ExposeConfiguration(cfg => new SchemaExport(cfg).Execute(true, true, false, _connection, Console.Out));
});

return nhConfiguration;
})

After this definition, we have to define which SessionContext uses which connection string for connect to database and creating session factory.

[DependsOn(
typeof(StoveNHibernateBootstrapper)
)]
public class StoveNHibernateTestBootstrapper : StoveBootstrapper
{
public override void PreStart()
{
StoveConfiguration.DefaultNameOrConnectionString = "data source=:memory:";
StoveConfiguration.TypedConnectionStrings.Add(typeof(PrimaryStoveSessionContext),StoveConfiguration.DefaultNameOrConnectionString);
StoveConfiguration.TypedConnectionStrings.Add(typeof(SecondaryStoveSessionContext),StoveConfiguration.DefaultNameOrConnectionString);

DapperExtensions.DapperExtensions.SqlDialect = new SqliteDialect();
DapperExtensions.DapperExtensions.SetMappingAssemblies(new List<Assembly> { Assembly.GetExecutingAssembly() });
}
}

As you see connection strings are same but they are inside of different StoveSessionContexts. If these entities are inside of same database but you want to treat as different bounded contexts to them, you can choose this kind of approach for your sessions. Otherwise entities can sit together in one SessionContext.

Usage is always same and persistence agnostic:

using (IUnitOfWorkCompleteHandle uow = The<IUnitOfWorkManager>().Begin())
{
The<IDapperRepository<Product>>().GetAll().Count().ShouldBe(1);
The<IRepository<Product>>().GetAll().Count().ShouldBe(1);

uow.Complete();
}

Document Databases

  • RavenDB -> IRepository
  • Couchbase -> IRepository

Queue Mechanism

  • RabbitMQ support

Background Jobs

  • HangFire support

Caching

  • Redis support

Others

  • A lot of extensions
  • Strictly SOLID

Composition Root

IRootResolver resolver = IocBuilder.New
.UseAutofacContainerBuilder()
.UseStove<StoveDemoBootstrapper>(autoUnitOfWorkInterceptionEnabled: true)
.UseStoveEntityFramework()
.UseStoveDapper()
.UseStoveMapster()
.UseStoveDefaultEventBus()
.UseStoveDbContextEfTransactionStrategy()
.UseStoveTypedConnectionStringResolver()
.UseStoveNLog()
.UseStoveBackgroundJobs()
.UseStoveRedisCaching()
.UseStoveRabbitMQ(configuration =>
{
configuration.HostAddress = "rabbitmq://localhost/";
configuration.Username = "admin";
configuration.Password = "admin";
configuration.QueueName = "Default";
return configuration;
})
.UseStoveHangfire(configuration =>
{
configuration.GlobalConfiguration
.UseSqlServerStorage("Default")
.UseNLogLogProvider();
return configuration;
})
.RegisterServices(r => r.RegisterAssemblyByConvention(Assembly.GetExecutingAssembly()))
.CreateResolver();

var someDomainService = resolver.Resolve<SomeDomainService>();
someDomainService.DoSomeStuff();

Packages

Contributors

Languages