Menu
I have the following setup: MVC > Services > Repositories. Now I want to allow users to be able to add a Note to a Document. Only Users associated with the Document (either as owners or reviewers) can add Notes so in my NoteService I do the following to ensure the User has permission on the selected Document:
public Note GetNewNote(int documentID)
{
if (!userHasAccess(Thread.CurrentPrincipal.Identity.Name))
throw new BusinessLogicException();
// Other stuff here...
}
My question is, where should I define the userHasAccess method? It makes no sense in the NoteService as it is checking on a Document. I could define it in the DocumentService but will then NoteService will need access to this which seems to be introducing more coupling.
To me it makes more sense to define it on the Document POCO itself and then call document.userHasAccess(...). Would this be good practice or should a domain POCO be limited to simple properties? I am concerned that this is really part of the validation and that by placing the method in the POCO I am seperating the validation between Service and POCO.
What I am trying to ensure is that my application is easy to maintain and test. Any suggestions on how I should tackle this would be most appreciated!
296
A POCO is your Business Object. It has data, validation, and any other business logic that you want to put in there. But there's one thing a POCO does not have, and that's what makes it a POCO. POCOs do not have persistence methods.
These classes (POCO classes) implements only the domain business logic of the Application. Some developers use Data Transfer Objects (DTOs) with the classes to pass the data between the layers because POCOs are also used to pass the data between the layers, but they become heavy.
To create POCO classes, we first need to disable auto create classes or auto-create code generation, which generates Context classes entity code in Model1.designer.cs.
How to Create a POCO class in entity framework, integrate it with ObjectContext and write queries To create a POCO class with the database-first development approach, we will first create a model for Sales Order Management system database and then create classes and make them interact with Entity Framework.
Now, we must create properties (Context and Entities), so for this, we need to create POCOs classes. Now, double-click on Modal1.edmx and right-click on the designer surface and click on the code generation Items. A screen will open from where you need to select ADO.NET POCO Entity Generator and click Add.
To create a POCO class with the database-first development approach, we will first create a model for Sales Order Management system database and then create classes and make them interact with Entity Framework. There are many tables in the Sales Order Management (SOM) database.
Where should I define the userHasAccess method?
It makes sense to be consistent with the rest of the design, while I don't know the full design I can at least say that a method called UserHasAccess() on the POCO itself makes sense.
Should a domain POCO be limited to simple properties?
No, a domain POCO should contain logic (especially validation logic) related to the object. Otherwise, it ends up being an object with no behaviour - something you should definitely avoid.
However, don't get confused between a domain (business) object and a view object, which will typically contain little logic.
You are concerned that you are separating the validation between Service and POCO.
I'd put validation in the POCO, and cross-domain logic in the services.
163
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
