DATAONION IS DEAD - YOU SHOULD BE USING CLEAN ARCHITECTURE

Support for Entity Framework 7 is now available.

During 2018/2019 we have moved away from using Data Onion to automatically generate repository classes and instead follow this MediatR rule: https://rules.ssw.com.au/use-the-mediator-pattern-with-cqrs

Another problem is that .NET Core does not have an implementation of T4 templates – which seriously limits where this library can be used.

“No, the repository/unit-of-work pattern (shortened to Rep/UoW) isn’t useful with EF Core. EF Core already implements a Rep/UoW pattern, so layering another Rep/UoW pattern on top of EF Core isn’t helpful. A better solution is to use EF Core directly, which allows you to use all of EF Core’s feature to produce high-performing database accesses.”
– Jon Smith https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/

Die-hard fans of building repositories on top of EF Core should investigate Steve Smith’s Specification Pattern examples:

Introducing SSW Data Onion

Integrate Entity Framework into your Onion Architecture Enterprise Application

onion architecture

Figure: The Layers of the onion architecture – as per ssw rule The Layers of the onion architecture

When building enterprise .net applications you should follow the Onion Architecture as outlined above. This domain model-centric approach encourages the development of maintainable solutions by integrating loosely coupled components via interfaces.

Adopting Onion architecture can lead to writing lots of extra code. SSW Data Onion makes this easy by generating an Entity Framework Code First implementation for persisting your Domain Entities.

In a nutshell

Figure: The Layers of the onion architecture explained

Figure: The Layers of the onion architecture explained

  1. SSW Data Onion contains 3 .tt templates that read domain classes from your appropriate domain assembly
  2. We generate a repository interface for each domain class.
  3. We generate a default EF Code first repository implementation for each domain class.
  4. The DbContext also needs to reference every class so we also generate that.
  5. We also have a set of core classes to support:
    1. Dependency injection of DBInitializers http://www.entityframeworktutorial.net/code-first/database-initialization-strategy-in-code-first.aspx
    2. Managing DbContext lifecycle in a unit of work pattern