While designing (and then implementing) a layered application:
Is it correct to use the same ORM objects accross all layers? (which would go against encapsulation).
Or the presentation, business and data layer should each have their own objects? (which would lead to lots of code repetition).
e.g. (just to illustrate the question): if one uses Linq to SQL in the Data Layer and Visual Studio's O/R designer to generate the ORM objects, are those objects supposed to be used in the Business and Presentation Layers as well.
i.e.: Are the objects associated with the entities that the application handles a crosscutting issue?
It depends by your business. if you are talking about a small application you could do it.
Usually the best practices wants to don't expose the entity from the DAL to the presentation because doing that the layer are going to be tightly coupled and you could expose data that doesn't make sense at the top layer (presentation)
on the other hand you shouldn’t create a bunch of object per each layer.
it's always hard answer this question because it really depends by your needs.
you can have a look at this book just to have an idea about
http://books.google.co.uk/books?id=FyWZt5DdvFkC&printsec=frontcover&dq=martin+fowler+enterprise+architecture&source=bl&ots=eEEx4ATr5C&sig=sSmDmffOSALWfFZEaPyhkwwEq_I&hl=en&ei=SJnSTMuSJIHm4AaK9tW5Dw&sa=X&oi=book_result&ct=result&resnum=6&ved=0CDAQ6AEwBQ#v=onepage&q&f=false
Related
I'm having problems to understand the conception of DDD. I have an ASP.NET project with this structure:
ASP.NET MVC4 project: xxx.UI.Web
Class Library project: xxx.Application xxx.Domain xxx.Infra.EF
I'm trying to keep this relation:
xxx.UI.Web only have relation with xxx.Domain and xxx.Application
xxx.Domain doesn't have relations.
xxx.Application have relation with xxx.Domain and xxx.Infra.EF
xxx.Infra.EF have relation with xxx.Domain
But now I'm having many problems to keep this concepts with Entity Framework. I have created the Entity repositories in the xxx.Infra.EF and created a generic repository (with interfaces and so on) in xxx.Application.
The problems begin when I need to pass a personalized Entity context to my repositories, because I use the repositories in the xxx.UI.Web and I can't instantiate a new Entity context because It will broke my project pattern (The Entity context comes from xxx.Infra.EF).
My idea is to create many helper methods that will process this kind of operations for my xxx.UI.Web, and I wouldn't like to create this methods in xxx.Application (It looks a little strange to create many methods with a little relation with my business logic).
So I was reading a little about Domain Driven Development (DDD) and I knew about the Service layer, and I think It seems to be the layer that was created to solve problems like this, or not?
My idea is to create a new class library project called xxx.Service and make this project keep relation with xxx.Domain and xxx.Infra.EF. Is It right? I know that I could search for another solutions for my case with Entity context, but I guess I'll have more problems like this in the future with other things, so I tried to find solutions for It. I should study much more about It, but I think I could identify the solution for my problem.
I suggest you further study the concept of layered architecture.
You are correct that the Domain should not reference other layers, such as the Presentation Layer and Infrastructure Layer.
The most common style of layered architecture is the "Onion Architecture". See image and link below.
http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
The Service Layer
You are also correct that a new layer (Service Layer) will solve your problem. You see, the problem arises because the UI/Presentation Layer is talking directly to the repositories(Infrastructure).
In our approach, the Presentation Layer does not communicate directly with the Infrastructure and Domain. We have a Service layer that comes between the Presentation and the Domain.
The above architecture borrows heavily from the Onion Architecture. We don't have domain services. Application Core is our CrossCutting Layer.
People often misunderstand the point of a multi-tiered application. The goal is not necessarily to remove dependencies, but rather to encapsulate and modularize code. Your MVC frontend shouldn't need to be concerned with your entities and how their queried, added, updated, etc., but it doesn't mean it doesn't need access to them. Long and short, don't focus on project references, but rather factoring out code that is not in each project's "domain" into a more appropriate "domain".
To that end, it's not really possible to say based on the information you provided exactly what you should do. The question is opinionated to begin with and will very likely end up being closed as a result. Ultimately, you have to decide what's best for your project. Do what makes sense, rather than blindly following some pattern. After all, patterns are supposed to just be a codification of common sense approaches to common problems, anyways.
I am making asp.net site using Layered architecture. Can I implement and use Data-Set object in presentation layer?
I simple layered architecture might have:
Datasets being populated in the DAL
Business Entities / Domain objects in the 'BLL' are populated from the DAL Datasets
The presentation objects are pretty simple data transfer objects that match whatever is being presented.
Obviously there is a bit more to it than this.
Pluralsight have just released a course that might be worth your time?
Data Access Layer and Business Logic Layer is better place for it. To get more insight try Creating a DAL and Creating a BLL.
Obviously You can use it, but layered architecture is all about separating layers.
For interacting with database, you should use Data Access Layer.
You can have a look the aim of data access layer.
What is the purpose of a Data Access Layer?
So I am thinking of using LLBLGen Pro and Spring.Net on this asp.net project using a service layer to decouple the Business Logic from the Data Store. I am also considering using PONOS in the UI Layer, now my question is:
Should I Map the rich LLBLGen Entity Objects to Ponos in the Data Layer or in the Service Layer? If I do it in the Data Layer then I loose all their rich functionality in the service layer. Or should I just skip the mapping to Ponos and use LLBLGen entities all the way through? If the later it will be harder to test it right?
Can someone give me pros and cons of both approaches?
Thanks
The upside of using LLBLGen Entities with no mapping is that you get entities generated right from your database schema (or even with no database schema in LLBL 3.x), so you can have a very usable entity model in a matter of minutes. The downside is that your entities inherit from LLBL framework classes, which makes them harder to enrich with behavior/business logic. If you generally design your biz logic as a set of services, this won't pose a problem.
I don't see testing as a problem in this scenario, as I generally view the entities as "anemic" data objects, and I generally don't mock such objects (no real reason to do so).
The upside of mapping to POCOs is that you have full control over the design of your domain/entity/DTO objects, and they can be as rich or as anemic as you want. The downside is that you will have to design and code the POCO classes and the mapping, and (as you said) you will lose some functionality like change tracking that is built into LLBL Entities.
I personally choose to use the generated entity objects unless I have a very good reason NOT to.
I'm working on a fairly large project at the moment and am currently in the planning stages. I've done a lot of reading into the various patterns suggested for development, somthing that has split the team at the moment is when using Entity Framework should the classes be passed through the applciation layers so that a view accepts an Entity Framework class or should these classes be mapped to BLL Classes and if so at which point (Controller or Library) should this be done?
I'm interested in hearing some positives and negitives for each solutions.
This is one of those great "it depends" questions ....
For me it's a matter of pragmatism. I use the raw entity classes where ever I can for expediency. I start using DTOs when either the object graph in question starts becoming too cumbersome or the object in question has sensitive data I don't want sent over the wire.
This is again one of those questions that doesn't really have a right or wrong answer, its personal taste really. Personally I would opt for using DTO's or interfaces when passing data to the Views. I don't tend to pass around entity objects to different layers of my application they are strictly confined to the DAL, or if I do need to pass it up a layer I would almost always use an interface never the concrete type.
I was looking for some feedback on the current design.
Here is how it currently looks
Web App (UI) References BLL Layer and BusinessEntities Layer
BusinessEntites Layer - Contains Interfaces and Classes (with internal validations on the properties)
BLL (references the BusinessEntities and DAL Layer) - Has mostly Managers for each of the Business Objects with methods like Create() Save() Delete().
DAL (references BusinessEntities Layers) - Has DB commands that create/add/update Business Entities Objects.
I'm not quite sure about the naming conventions i used for the layers so if anyone has any better suggestions than i'll gladly adopt them.
Also i don't like the idea of the DAL referencing the BusinessEntities Layer, but how else am i going to return objects instead of Datasets/DataTables?
Thanks for any feedback.
With respect to your needing to reference the business layer from the DAL, I would agree that this is probably not optimal -- lower tiers should not know about the ones above them, it reduces reusability and adds extra/potentially circular dependencies.
Have you considered having your business entities "fill themselves up" and do their own persistence operations using the DAL classes, rather than the DAL acting like a factory for them (as in your current design)? That way, your DAL would be a more direct representation of the database, and the business entities would contain the (business) logic needed to fill and persist themselves appropriately.
Also, the "BLL" layer you spec out doesn't really appear to me to contain business logic; it looks to me to be more of a persistence services layer for the entities.
So a variation of what you propose could be:
Web/UI, referencing Business Entities
BusinessEntities, contains interfaces and classes with business logic. References DataServices layer
DataServices, contains classes that load, find and persist data. Can serve up "generic" structures containing the data (Data Transfer Objects) that can be produced, consumed and processed by Business Entities. References DAL.
DAL, which simply provides classes that map to tables.
Depending on your requirements, I would consider merging your BusinessEntities and DataServices (BLL in your original design) into a single tier; the only reason I can think of to split them apart is if you are doing something like Silverlight where you need asynchronous data operations on client-side business entities.
Of course all of this is with an incomplete knowledge of your specific system requirements -- you will need to design what is best for your specific application. Good luck!