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!
Related
I am trying to build a three tier architecture with UI, BLL, and DAL. I am using the Entity Framework with the repository pattern.
My question is: Are the Entities generated by the Entity Framework supposed to act as a part of my BLL or are these just DAL objects?
Reason for asking is because It feels like I am duplicating code. For example: I have a DAL.CatEntity which is generated by the Entity Framework directly from my database. This all fine and dandy. I then use my repository (which is part of my DAL) to pull data into a DAL.CatEntity. I then use this DAL.CatEntity in my BLL, pull out all of it's data, and transform it into a BLL.Cat. I then use this BLL.Cat in my UI layer.
Below is some super simplified code.
BLL
public Cat GetCat(string catName){
CatEntityRepository _repository = new CatEntityRepository;
Cat cat = null;
CatEntity catEntity = _repository.GetSingleCat();
cat = ConvertToCat(catEntity);
return cat;
}
private Cat ConvertToCat(CatEntity entity){
return new Cat(){
Name = entity.Name,
Color = entity.Color,
//....
}
}
UI:
public ActionResult method(){
Cat cat = BLL.GetCat();
//......
}
It seems unnecessary to have BOTH Cat and CatEntity. Can I just use my EntityFramework Entities as part of my BLL while using the Repository as my DLL?
Thanks.
Ultimately, whatever you do is up to you. Most apps are somewhere between ideal and horrible, in the land of pragmatic and practical.
What you need to do is look at the complexity of your app. The more complex it is, the more it will benefit from high degrees of separation. Often times the simplicity of the app just doesn't justify the large amount of work needed to create clear layers.
Having said that, in my opinion, in a large number of small to medium complexity apps, you can effectively treat your entities as business objects. In particular, if you make the entities POCO's and part of your business layer, then use those entities in your EF DAL, it can be quite efficient.
I would always caution, however, sending business or data objects directly to the UI. You should have dedicated UI objects that are translated between business and UI.
I think it makes the most sense to keep a strong separation between business and data when you might change your data access methods. For instance, if you think you may change to a web service to get your data rather than using EF directly. Also, strong separation of concerns helps a great deal with unit testing.
If you feel that you are duplicating code then you probably don't need a service layer and your EF entities could act as business models. This is often the case with simple CRUD applications in which you don't need a business layer.
An alternative approach is not to CONVERT between tewo types of objects but rather, create interfaces out of your domain entities and code your repositories against interfaces.
This way you bake two cakes in the same time. You don't convert your data layer entities to bll entities snd still you are not messing layers (in a sense that your repositories don't work on concrete data layer types).
This approach is suprisingly useful and yet rarely described.
I have four assemblies; UserInterface, BusinessLogic, DataAccess, Common.
The User Interface references the Repository that is in the DataAccess, is that bad practice? Should I create pass through methods in the BusinessLogic so that the UserInterface is not coupled to the DA assembly?
Even in cases where the BusinessLogic method does nothing but call the relevant Repository method?
Or am I being pendantic?
rather than think of the UI talking to the repository, think of implementations depending on abstractions. in this instance the UI depends on IRepository. How IRepository is implemented doesn't matter.
and putting this all into separate assemblies is overkill. just use namespaces to segregate your code. it will be much easier to maintain.
If you are trying to do Domain Driven Design then please understand the role of a repository before you think of using it in UI. Very nice explanation here http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
I thnk you are missing a Layer. Entities Layer or Data Transfer Layer.
It's not definitely ag good practice, an UI have to know knothing about your DAL, that's why You have Your business Layer.
I think You should do it the classic way UI - BL - DAL and backwards should be the same, using Data Transfer Objects
Always using DTO between these layers, transfer objects from the UI to the BL, from BL to the DAL and that way backwards.
I think the main reason of layered structure is 'Seperation of Concerns'. SoC is basicly offer loosely coupling. So reference of UI in DAL is not good thing.
On the other hand, UI should take care of user interaction (not directly calls from DAL). BL should take care of validation and call DAL methods. DAL is the final step and it can validate datas in according to SQL aspects, then handle SQL Statements.
I have a ASP.NET MVC solution with three projects:
SquarkMVC
SquarkBLL
SquarkDAL
The SquarkDAL layer has Linq2SQL classes for each object in the DB. BLL references the DAL in order to conduct business logic on the DB.
My question is this... without having to reference the DAL in the MVC layer, how should I model the entities of the DB in the MVC layer? For instance, if I have a sign up form in the MVC layer, what is the best way to take that information, pass it to the Business Layer which then passes it on to the Data Layer? I don't want the MVC layer to know anything about the DAL.
I've found this answer on another post... is it generally agreed that the best way to overcome this is to create a transfer object in order to pass the information from the presentation layer, to the business layer, which will then convert the information into the entity classes used by the DAL?
Hope this makes sense.
Using objects is a common way to do this. Usually DTOs (Data Transfer Objects) are "dumb" POCOs having a set of properties, and acts like a "struct", but, if you put on them validation and more logic (view logic) you have a view model and you can use them to work with the controller. This one should use the model (of the Business Layer).
More, Business Layer should never having a reference to the DAL, because your business model should be independent by the storage.
Instead, the data access layer should reference the model, and choose the right way for persistence. You can achieve it with the Repository pattern.
Anyway there are a lot of books about domain driven design.
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.
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