Remove SQL and add database schema migrations for testing purposes.

The Unit of work pattern is needlessly complex. State management can be moved to cache, or scoped object collection. DataProvider is wildly inefficient. Since .NET 6 only allows TransactionSCope to participate in one database transaction at a time, there is not currently a need for multiple transaction providers. The exception to that rule would be if Mongo db client requires a different provider. In that case though, we should be able to detect the DataStore type and dynanically switch transaction providers when using IUnitOfWorkScopeFactory.

Attach method needs to ensure that object graph is populated prior to attaching, otherwise it will assume it is already done and then attempt to attach which will generate errors with identity inserts, foreign keys and such. Something along the lines of Find(key) needs to be used first.

Create sample code for a simple console application. Sample code should include configuration, basic Crud operations via repository pattern, transactions via unit of work pattern, and exception handling.

Create template abstractions for common implementations:

• Theming
• Email templates

Will need to take into account some sort of database driven templates for Razor and maybe another mainstream provider.

Consider creating a virtual file system configuration interface for pluggable web application architecture. Should also consider using database driven file system using an extension of IFileProvider such as this: https://github.com/nibblesnbits/TemplateFileProviderDemo

Add wrappers for MassTransit interface and messaging abstractions to support distributed architecture.

Need a simple CA/CQRS sample to assist with demonstrating how to use RCommon. Scenarios that should be covered:

• Dependency Injection via Adapters
• Mediator
• Repositories w/ EF
• Business Entities base classes
• Model/DTO base classes
• Unit of Work pattern & behavior
• DTO validation

Add multitenancy support for entities, and persistence operations. Needs to include tenant resolver for the following scenarios:

• Web/identity claims
• Web/session
• Web/Cookie
• Web/Domain Http Header or URI
• LocalThreadContext

Tenancy Models to support:

• Single Tenant (One Data Store per Tenant)
• Multi Tenant (One Data Store per Multiple Tenants)
• Mixed Mode (Possibility to separate certain Tenants from multi tenant data store based on criteria)

Will also need to create connection string factory to support dynamically changing connection strings based on tenancy model.

We currently have an SMTP implementation but need to implement SendGrid Email API as it tends to perform better and is generally excepted by the community.

Extend exception handling to include support for uncaught exceptions in web and non-web applications.

Removed need for IStorage and supporting classes. We can now use things like IMemoryCache and Scoped objects for storage.

Create a SMS abstraction with the following implementations:

• Twilio
• Null

Need to add the ability to perform soft deletes vs. hard deletes. Things to consider:

• Configuration to be applied at global level with default set to hard delete.
• Configuration to be applied at Repository level where parameter can be used to ignore/override global configuration

Need to create ChangeTracking abstractions for generically capturing entity changes and properly persisting them. Each individual repository implmentation (EF Core, NHibernate, etc.) has their own strategy for change tracking with various pros/cons. This makes creating a pattern around those libraries difficult so it makes more sense to abstract out the implementations. There are various libraries that can handle this sufficiently.

Need to deprecate IQueryable methods such as FindSingleOrDefaultAsync, and AnyAsync. IQueryable has had implementations for all this for a while.

Dapper extensions are not allowing for pluralized table names and extension api does not appear to want to let us change convention through startup. https://stackoverflow.com/questions/32204808/dapper-use-singular-table-name

Need to implement basic support for event sourcing. The majority of the functionality already exists via the local/distributed events but we'll need to ensure we're capturing new/previous state in all local/distributed events and we'll need to add some configuration/extensions which allow us to determine storage queue for events.

Candidate Implementations:

• EventStore
• MongoDb
• EF (Transactional RDBMS)

Add support for MongoDb using IGraphRepository interface. Full integration test suite should be included.

Need integration tests for background jobs:

• Background job managers
• Quartz job managers
• Hangfire job managers
• Rabbit job managers

Create the documentation neccesary for a developer that is new to the framework to easily and successfully implement the framework in a few minutes. Sample code should be referenced for continuity.

Paginated ListModel Requires new() constraint on classes which prevents Model classes from using parameterized constructors - the preferred means of creating a DTO or record.

All repositories currently are required to have "DataStoreName" property set at instantiation. There should be a mechanism for defining a default data store in options through DI. Also, factories would be a nice addition during options to allow repository to dynamically figure out what datastore to use based on certain conditions.

A more robust event bus interface should be created. MassTransit should be an implementation of IEventBus rather than a first class citizen.

MongoDb does not appear to have a native in-process change tracking solution such as EF or NHibernate. We'll need to implement something in order to satisfy the IGraphRepository requirement.

Create blog storage abstraction with the following implementations:

• Azure
• AWS
• File System
• Minio
• Aliyun

Consider using ABP for much of the plumbing code.

Currently the RCommon.BusinessEntities.ChangeTracker implementation is geared more towards eventing of the business entities rather than the changes being made to them. While there is a fine line, the prevailing wisdom is that changetracking has more to do with state of the entity and the ability to capture changes in state, whereas the current implementation of RCommon ChangeTracker deals more with the event capturing - an event repository of sorts. There is a clear separation of responsibilities here.

• Consider wrapping EF ChangeTracker which would be suitable enough
• NHibernate seems to have mechanisms in place to handle change tracking which could be wrapped
• Special consideration may need to get made for MongoDb

Serious consideration should be put into migration all dependency injection registration to the IServiceCollection interface. The community seems to have adopted that pretty heavily. Most DI container providers have to adopt this at some level. It may make sense for RCommon DI to adopt that as well and let the DI providers drive adoption of their specific interface and features separately. RCommon doesn't gain anything from allowing architects to use a consolidated interface for DI registration. Architects don't gain anything from being able to consolidate a DI registration interfaces unless it has the benefit of wide community adoption. Lastly, architects are forced to adopt at least the version of RCommon DI abstraction that has been implemented which may be the biggest reason for inability to adopt.

• MassTransit has recently moved to this strategy
• MediatR has implemented this strategy
• Windsor has moved to this strategy

Need to either create validation abstractions or promote Fluent Validation library to first class citizen. There are currently two conflicting sets of validation classes in play 1) Original NCommon/native validations 2) Fluent Validations. Fluent Validations obviously has a lot of support, while the native validations support more generic validations via specifications supported by RCommon.

Look into:

• See if we can implement specification based validation in Fluent validations and tie that to a generic interface/abstraction
• Decide if carrying around native validations is worth it assuming we'll have to create some consistency between libraries.

MassTransit has a good implementation for mediator pattern which would extend RCommon's depth in the MassTransit/messaging ecosystem in addition to expanding Mediator implementations.

https://masstransit.io/documentation/concepts/mediator

CancellationToken is missing from most async operations which will prevent thread cancellation downstream in the framework.

Add ability to fully audit all entities persisted in data store. Basic functionality should include:

• Track who executed action
• Track what action was affected
• Track when the action occured
• Track previous state

Need to add localization abstractions with support for the following configuration providers:

• Resx
• Json File
• Data Store

This should also consider how localization is resolved:

• Config/Options
• Url resolver
• Cookie
• Session
• Tenant

Add optimistic and pessimistic concurrency support to entities and persistence.

Add base classes for entity persistence which support persistence events for both local and distributed architecture.

Add Linq2Db support https://linq2db.github.io/ with ILinqMapperRepository implementation. Should include full integration test suite.

Update CommonApplicationServicesConfiguration to use extensions for IOptions pattern for setting Email Settings in fluent configuration.

There is not currently a way to add audited entities to RCommon data stores as there is not currently the ability to acquire data such as "user" from a given context. Audited data stores should allow:

• LastModfifiedDate
• LastModifiedBy (user)
• DateCreated
• CreatedBy (user)

User info should be acquired through a factory (default should be identity). Also consider using change tracking to discover whether or not entities are new vs. updated to auto-populate properties.

Options pattern should be used to determine rules for how audited entities get populated.

Currently, unit of work does not fire unless one has already been created. There is no need to detect unit of work since all transactions are ambient at this level and will auto subscribe. Also, the behavior will ensure that only one unit of work is created per request scope....though we can continue to create new ones (suppressed or otherwise) if needed in the pipeline.

There are a number of references to LGPL code references - primarily related to ABP. This limits commercial adoption.

Create a full suite of integration tests for EF core which will ensure this EF Core implementation works from the top down. Tests should include CRUD functions, transactions, web based and non web based tests.

To meet the standards of our release criteria, we can only release code which has been adequately unit tested. As a result, we should remove NHibernate and defer it's release to a future version. Additionally, we should smoke test the samples to ensure all functionality works. Documentation also needs to be updated to ensure at least a minimal amount of samples for each section.

The current implementation of tracking changes in EF leaves much to be desired. Tracking should be allowed on a per-entity basis as well as repository level.