In a three-layered architecture, where is the DAO pattern located? Is it in the business logic layer or in the data layer?
I'm not sure that thinking in terms of layering is useful anymore.
We used to have 2-tier client-server, with all the logic in the client and a database running on a server.
We evolved to 3-tier, usually associated with MVC model-view-controller. There wasn't a mention of data access objects in the original Smalltalk MVC pattern.
Now I think view and controller generally go together, splitting rendering of the user interface between client and server. Controllers have business logic and interact with many web and data access services. Data access objects would be used by controllers to deal with data sources. Call that whatever layer you wish.
I don't think of microservices as a layer. Perhaps the usefulness of the concept has diminished.
Related
we use html 5/angular SPA with Webapi at the service which communicates with DAL for dataaccess operations
Layer flow would be:
presentation(html5/angular controllers/service) --> web api --> DAL - -> DB.
we do not have BLL project as such. we are thinking to make DAL as combination of BLL + DAL. And we use DTO objects created through t4 templates and they are used for transfer of data between client and web api and DAL (we dont use EF, we use ADO.Net as underlying provider)
should we require a seperate BLL project or is it ok to combine BLL and DAL proj? considering it should be testable and extendable.
as mentioned, DTO objects are used throughout. should we require any model other than DTO to transfer the data between the client and webapi/DAL?
DAL :
public List GetCustomers {} this uses Data access helper classes to get the customers and convert to DTO
above CustomerDAL.GetCustomers is being called by webapi project. At this point of time, any BL of (say. customer) is written in web Api project and sometimes at DAL project. we are thinking to move them to one project for consistency and testability.
any insights on this would be helpful.
The greatest value that I get out of having a separate BLL is that the most important / expensive bits of my application (the business logic), are in an area that has no dependencies on databases or web/http frameworks. It means that when the next big thing (database, platform, etc) comes along, I can reuse my business layer.
More importantly, DAL and UI layers are MUCH more expensive to test. When I'm writing unit tests at the UI or DAL layer, I'll end up testing 1-2 scenarios per function... When I'm testing at the BAL layer, I'll create many times more scenarios, because it's so cheap (effort-wise). This gives me much better coverage for much less cost.
Perhaps your applications don't have much business logic. If they are purely CRUD wrappers around database tables, it might not justify the expense. Most applications contain far more business logic than the developers want to admit though. Look through your validations that you run in your WebAPI... Those are likely all business rules. Look at your security constraints, those are likely business rules as well.
Whether or not to use DTOs or a more complex domain model depends on your design, environment, and team constraints, and is not something I would feel comfortably addressing in a fifteen minute posting. Fowler has some strong opinions, calling it an Anemic Domain Model antipattern, but I've seen it used quite successfully for large-scale projects. One of the nice aspects to this model is the fact that you don't need quite as much of a coherent picture of the application model, which is often the case with large, dispersed teams.
Folks,
Apologies if this has been covered in another thread, but I have searched ddd and mvc articles and have not found a straightforward answer.
I am hoping to apply a DDD approach to the architecture of my MVC projects. Please correct me where I am wrong.
All MVC controller actions that involve hitting the domain model will initially hit
and application service layer.
The application service layer here acts as a facade between presentation and the domain.
Any requests from the application service later that clearly involve discrete domain aggregates will perform fetch or modify operations on aggregate roots using repositories. Each aggregate root will have its own repository.
so the application service layer must be injected with any/all repositories required by the domain.
Where an operation may involve multiple aggregates or requires logic that does not fit neatly into one aggregate, the application service will call a domain service to carry out operations across aggregates.
This does not seem right to me.
My confusion is that from a DDD perspective Im not sure whether for example aggregate roots should perform their own persistance i.e. the aggregate gets injected with a repository and then persists/fetches itself or whether as above the application service layer uses repositories to act on or fetch aggregates?
Also if the application service layer is injected with all repositories, does the domain service that the application service layer calls also need repositories injected?
Im keeping CQRS out of this at this point. I want to get the layering and the relationship between services and aggregates sorted out first.
Thanks for any advice.
All MVC controller actions that involve hitting the domain model will
initially hit and application service layer. The application service layer here acts as a facade between presentation and the domain.
There's debate over that but I would consider carefully whether that additional layer is needed or not. It adds a lot of boilerplate code and degrades maintainability - as someone pointed out recently, when you separate things that change for the same reasons (ie your service methods and the corresponding domain methods), you have to make changes in many different places in the system.
On the other hand, you could need that service layer to map your domain objects to DTOs but there again, it could be done directly in the Controller and nothing forces you to use DTOs in the presentation layer.
My confusion is that from a DDD perspective Im not sure whether for
example aggregate roots should perform their own persistance i.e. the
aggregate gets injected with a repository and then persists/fetches
itself or whether as above the application service layer uses
repositories to act on or fetch aggregates?
It's usually considered bad practice to have aggregate roots manage their own persistence because it breaks persistence ignorance and violates the Single Responsibility Principle. If you do that, your aggregate root class now has 2 reasons to change, 2 reasons to break the code, it is less maintainable, etc.
You should instead delegate the responsibility of saving the aggregate root in its repository to an object that will be aware of the application execution context (for instance, a Controller or an object in the Application layer).
Also if the application service layer is injected with all
repositories, does the domain service that the application service
layer calls also need repositories injected?
Yes, I think it pretty much makes sense especially if the domain service heavily relies on the repository.
I was watching "storefront starter kit", its using repository pattern with service layer. In the video, he didnt really explain why he's using service layer. Seems like those are just extra.
what are pros and cons using service layer?
Repository is your Data Layer ... it's responsibility is to fetch and save data.
The Service Layer is your Business Layer ... it's responsibility is to hold all your business logic.
For most asp.net mvc apps it is perfectly reasonable and preferable for your controllers to directly address the repository (via an interface). I would only add a service layer when you need to, for example when other apps are interfacing with your application. In my opinion you should avoid unnecessary abstraction layers.
In the MVC pattern, the controller is the least reusable, compared to the other two aspects.
Now let's say I have an app (say for Ordering Pizza), which is available both as a web app and a mobile app (say iPhone). So in that case, I think the model (or data) can be reused. The view might not be reusable.
But regarding the controller, is it possible to reuse anything? Let's say if I already have a working web app, can I reuse controller logic for the mobile app as well? Also, what is and where exactly does "business logic" reside in MVC?
The controller calls a service layer. The service layer uses the model to do business logic. Controller never contains business logic. It should only delegate work to the service layer. I consider the service layer as the part that the domain model exposes, you could say it is the "Model" in MVC.
That said, I don't think the MVC frameworks really care if the controller is reusable or not. The important part is the model, which should not change because the service layer code is reused. Besides, if we write our code correctly, the controller will be a very thin layer and reusability should not be a concern.
Can you reuse the controller logic from the web app for a mobile application? I think not, but you could use the service layer. I am sceptical if even the view can be used directly from web to mobile apps, the needs are so different.
I suggest you look at Domain driven design if you are interested in application design and learning how to organize business logic.
Is to possible to have a layout for web-based architecture based on MVC where SOA is the architectural style. Or to rephrase, can services be part of the M,V, C of MVC.If so, what kinds of services can be included in each of them. Also, can you give me a real world example?
In a SOA application you are typically not including the front end (presentation layer). You are consuming those services in your MVC application, or better yet in a separate "model" project that the MVC application uses.
Data Access -> Business Logic -> Services -> Models -> MVC
The point is to use the services to create an abstraction around the base of your application to allow for multiple clients to consume those services.
I tend to term the Model as represented in the client/presentation layer as the ViewModel, it is simply the presentation layers view of the model. Not the actual Domain model.This is needed in a SOA as the context of the consumer of the Model changes often
In SOA`s we try to get to a canonical schema for the contract, as it is quite likely that not all clients now and in the future will require the exact same view of the model.
Thus be it a web client, service client or a desktop client, if you think of the Model in MVC as the ViewModel, this allows you to abstract presentation layer things away from Service layer things, and you get closer to a canonical schema.
So an example View >> Controller >> ViewModel(Model) >> Data Contract >> Service
Examples of how to build a service stack like this can be found here:
SOA Design Pattern
The decision of whether to go with a REST architecture or a full WS-* SOAP is a separate concern and should not affect your choice of MVC as a presentation pattern.
There may of course be other constraints that preclude the use of one or the other.
Choosing a presentation pattern for a new or enterprise web development on the Microsoft platform is a daunting task, in my opinion there are only three; View Model, Model-View-Presenter (MVP) or ASP.NET MVC (a Model2 derivative).
You can read the full article here ASP.NET MVC Patterns
This depends on what you mean by SOA. If you are referring to WS-* standards, I would not recommend MVC, as you will need to write a lot of plumbing to get it to work.
If you are looking for something like a REST service, then the MVC pattern actually works quite well. The request is the HTTP location of the resource, which gets passed to the controller, which loads the data via the model, and then passes it to the view which returns it in whatever form is needed (JSON, XML, Binary, etc). Or, you can often return the result directly, depending on what framework you use.
Erick