I'm working on a project that follows the Clean Architecture pattern, and I'm using ASP.NET Core Identity to handle authentication and authorization. I have a User entity that inherits from IdentityUser, and I need to establish many-to-many relationships with other entities in the domain.
The problem is that I can't add a dependency on Microsoft.AspNetCore.Identity.EntityFrameworkCore to the domain layer, as it would violate the dependency rule. Therefore, I decided to move the User class to the infrastructure layer, where I can have a reference to Microsoft.AspNetCore.Identity.EntityFrameworkCore. However, this created a new issue, as I can't use navigation properties to configure the relationships with other entities from the domain layer.
What's the best approach to handle this situation? Should I move the User class back to the domain layer, even if it means violating the dependency rule? Or is there a way to configure many-to-many relationships without navigation properties, while keeping the User class in the infrastructure layer?
I'd appreciate any guidance on this topic. Thank you!
I want to use navigation properties freely. But I don't I want to violate essential rules.
Related
having looked at Domain Driven Design and read about Anaemic Domain Models being an antipattern, thinking ok perhaps should put more behaviour into our domain entities. The Behaviour will need handling for flexibility using SOLID approach, hence the need for a DI framework and container to allow injecting some behaviours into the entities.
However there appears a mismatch in wiring up the Entities, as our Entities would coming from an ORM framework such as Entity Framework or NHibernate, and Behaviours coming from a Dependency Injection container.
I guess you need a way for the ORM to also have a DI Container plugged into it.
Just wondering how others have approached this when wanting to get more rich models but also use ORMs and DI containers.
1- It is not a good idea to use ORM entities as your domain entities. Because your domain entities constitute the core of your DDD application and should have the minimum dependencies. What if you decide to change your ORM in the future? ORM can be used in your Repositories but remember that you need to map the ORM entities to your domain entities before your repository returns them.
2- Your domain entities should have behaviors but they are limited to that entity only. Any behaviors that involve other services or dependencies should go to a domain service. So your domain entities wouldn't have dependency on other services. They usually don't even need abstraction, so they won't need to be resolved using an IoC container.
I came upon one potential answer after watching this excellent video by Jimmy Bogard on Crafting Wicked Domain Models.
So your domain model contains the behaviour and rich methods, but you inject into the method of the domain model specific behaviours which implement some interface and are bits of functionality that you can get out of a DI container.
So by altering what you inject into the model, we can alter its behaviour using DI whilst still having a rich domain model and retrieving it from the database via an ORM.
just starting with DDD. I understand that all the domain entities and their logic should be kept in Domain layer along with repository interfaces. In my application I store some data in the database that is used to construct parts of the user interface (presentation layer) at run time. Where should I keep the poco classes and repository interfaces for such types, in Application layer or Domain layer. I can not make out because these objects will not have any domain related business logic but they need to be hydrated from the database and I am using EF so for data access I will need entities and repositories so to me obvious choice is to keep them with all other entities and repository interfaces in domain layer but that breaks DDD rules
I think you've answered your own question:
In my application I store some data in the database that is used to
construct parts of the user interface (presentation layer) at run
time.
Access to data that is used to serve the UI should be encapsulated in the presentation layer. This is different from the application layer in that a DDD application layer implements use cases by orchestrating repositories and delegating to appropriate entities, domain services - it forms an API around your domain layer. Different presentation implementations can use the same application service.
However, different presentation layer implementations may require different data. Therefore, place presentation data access directly in the presentation layer. This can be implemented with EF which is not exclusive for DDD scenarios.
A good way to think of it is this - if you had to replace EF with stored procedures for performance reasons, you should not have to modify your domain code. So anything that blocks that needs to be hidden behind an interface and made replaceable.
Repositories CAN be a part of domain logic. However what should not be is the mechanism for persistence. This can easily be encapsulated into a DAL service or other object, which of course is programmed to an IDALService interface. So when you need to switch persistance (for example, moving from EF to a NoSQL solution) you simply write an alternative version that implements the IDALService interface, and you're good to go. The repositories can still do the logic within them, but are now using a new way to store them (this is an Inversion of Control idea).
As for the POCO objects, in DDD the real question is what do they represent? Are they entities, that need to be persisted? Are they value objects? Don't let the technology (EF) determine what the structure of your object model is, instead provide means to translate to an application scope.
In the Application layer. Keep the domain intact and isolated.
im doing some self-study on architecture of a MVVM-light - EF Application
im trying to build a product/Receipt like app.
I have a Db/EF with a Product and Receipt Table/Entity in a many to many relation.
then i have a DAL wich simply uses Linq to do simple CRUD.
the question is where and how to put my business logic in this app.
a couple of ideas came to mind
option 1
-make a ReceiptBo (Receipt business object)
wich inherit the Entity Receipt class and Icollection(ProductBo)
the ReceiptBo class would be responsible for adding Product,calculating total and subtotal and calling the Dal for inserting.
maby this option seemed a little overkill.
option 2
-put the calculating methods in the generated Entity objects by using partial classes
and simply using the BuisnessLayer to call the Dal.
this would make the Buisnesslayer Classes obsolete in my opinion and im not sure that Entity classes should be used for Business logic at all ?
option 3
-make the Business Classes but dont bother using inheritance, just add products to the Entity's and do the calculations there and call the Dal for insert.
wich seems simple but not very elegant.
option 4
-none of the above and im clueless
right now im not using WCF but the idea is that i want to make this app loosly coupled so that it would be easy to implement it and further extend it.
also im a little confused about what an Business layer is. in some examples it is more used like a Dal that also does the computing, then others say this is not done.
some help would be great. thx
ps: sorry for my bad english
Really, I would go simple here and choose a common multi-tier architecture designed as follows:
a data access layer (basically, your Entity Framework model along with all your entities)
a business layer that exposes methods to access to your entities (CRUD methods + any custom method that run some logic)
a service layer that exposes stateless methods through WCF (service+data contract)
the presentation layer (in your case using MVVM pattern)
Views (XAML pages)
ViewModels (C# classes)
Model is represented here by the entities that are exposed through WCF by the service layer
I wouldn't add any method directly in the entities. All methods are defined in the business layer, and exposed by the service layer.
Usually I keep my business logic in my ViewModels, not my Models, and I view EF objects as Models. At most, they'll have some basic data validation, such as verifying length or required fields.
For example, an EditRecieptViewModel would validate business rules such as verifying values are in a specific range, or verifying that users have access to edit the object, or performing some custom calculations when a value changes.
Also, don't forget that ViewModels should reflect the View, not a Model, so not every Model will have a ViewModel of its own
Given my understanding of MVC and DDD (critique as necessary):
Domain Models can be created by Factories, and persisted by Repositories. These are POCO objects.
View Models contain partial or complete Domain Models as needed by the view. They are generated by a service that interacts with a repository. Thus Domain Models never make it to the view directly. Likewise, ViewModels are never persisted.
You will very likely have multiple View Models for the same Domain Model because you could show it on multiple views.
That said, adding data validation to the Domain Model removes any kind of redundancy.
So how do you get the ViewModels to inherit the Domain Model data validation?
I wouldn't expect simply referencing a Domain Model from a View Model to work.
I asked this same question at the patterns & practices summit last October while speaking to Brad Wilson and he did not have a global solution.
One idea I discussed with him was extending an object mapping library such as AutoMapper to also map validation from the domain model to the view model.
In designing a framework to facilitate this scenario, some things to consider:
Validation rules may depend on the context and thus may be unique to the particular view model. The Enterprise Library Validation Block allows the setup of validation logic using a configuration file - this for example, could be extended to transfer to view models as well.
The View Model could have properties which are not part of the domain model, such as a property that specified that a certain "agree to terms" checkbox has been checked. This property requires validation however it is specific to the view and use case, not the domain model. This scenario serves as another argument to keep the validation logic separate, at least partially.
For the purposes of maintenance and clarity it may be easier to duplicate certain validation logic for the domain model and view model instead of using a mapping framework.
If I use ADO.NET Entity Framework in our project and we depend on a 3-layer architecture pattern that we have ( presentation layer - business layer - data access layer ) a project for each layer.
So when I make an entity model file where can I put it in the DAL or BL? If I put it in the DAL and from the presentation layer want to access a domain object in it through the business layer so we need to add a reference to the DAL in the presentation layer. Also, how do I get that type of an object as it is created in the DAL? On the other hand should I put the entity model file in the business layer? Which is the better and why?
Ideally, the EntityFramework generated code makes up your data layer. You would basically have some repetition then in your business layer if you needed the same sorts of objects in your business layer as you have in your data layer. Unfortunately, EntityFramework doesn't really help you at all with your business layer.
Now, you'll also read things about EntityFramework that say you can/should use it as a combined data/business layer. That violates Separation of Concerns, so I would guide you away from it, but I'm sure a ton of people do it anyway. If you wanted to move from EntityFramework to NHibernate some day, you'd be best off trying to isolate your ORM from the rest of your code base and minimize any coupling to the ORM (often through implementing something like a Repository pattern).
People who talk the language of MVC will often use EntityFramework as the Model and may or may not distinguish between a data layer and a business layer (which generally would both live in the Model). Even if you use MVC, I still believe you should decouple your data access from your business rules and business logic.
You can place the entities in a separate class library project, for example: Common Entity Library. This library can be referenced in any other app layers. You can then work with collections across application domain.
As I see it the Entity Framework is your DAL. It provides the needed tools to abstract the Model objects exposed by the Entity Framework from the persistance services of a backend database.
The Entity Framework straddles both the Business Layer and the DAL from this old three layer pattern. My advice is if you going with the Entity Framework is stop thinking in terms of Presentation->Business->Data and think more in terms of View->Model.