We're developing a layered web application. The specs:
3 layers, data layer, business layer,
ui layer.
Programmed in C#
Data Layer uses the entity framework
Currently we plan on having the data layer return IEnumerable<T> to the business layer via linq 2 entities, and the business layer will return data to the ui layer.
Since the ui layer has no knowledge of the existance of the data layer, how would it handle a result of IEnumerable passed to it from the BLL, where T is defined in the data layer?
Are there any GOOD example out there on how to do this. Please note that I'm extremely new to factories / interfaces / abstraction to loosely couple layers.
I saw the question here passing data in an ntier application and it was recommended to have the entity layer shared amongst all layers... however I do not want the other layers to be able to query the database.
Have your data objects defined in a separate project, or at least a separate namespace, so the Display layer can have a reference to the objects, but not the DAL that has access to the db.
Related
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?
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
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!