I am creating a UML diagram using COMET UML profile for my MVC application.
I distinguish between Information Model which describes the application entities, such as the domain model, and the Component Model, which describes the high level components of the application and the relationships between them.
In my case the Component Model describes database, Entity Framework, Repository, Service, Controller and Views. I grouped Entity Framework and Repository under Data Access Layer(DAL), the Services under Service Layer(SL) and the Views under User Interface(UI).
I have to find a place where to put the Controller (not a service nor a UI) and how to model the Database. I do not think it is a component but in UML there is no database object. Any tip on how to model them?
Related
I am new in MVC and little confuse and want to ask about differences and purposes of both.
MVC model and Business Logic layer (BLL) in tier Architecture.
What is the purpose and need to use BLL? some say they exchange the data between Presentation layer and data access layer. except these elaborate the BLL purpose.
So, we create properties in both MVC Model and BLL. So mention the proper difference and similarities if it has with the relevant code or example
Thanks
To me the M in MVC is about the view model used by the view. Each view has its dedicated view model, that contains all information needed by the view.
These view models are built in the controllers based on the DTO's that you receive from your back-end.
The BLL you are talking about is more the business layer on the back-end, which you don't know in your front-end logic. Often people use a domain driven approach or this layer.
I have been studying various patterns for layering an MVC application and need a little advice. What I currently have is the following:
1) POCO Domain Model, no business logic at all, so basically an anemic Domain Model.
2) EntityFramework with a Repository layer that hands back Domain objects.
3) Service Layer, now I am not sure if this an Application Service Layer or Domain Service Layer, but basically it is an API against the domain model. All of the business logic resides in this layer and assures the domain objects are valid, then hands it off to the repositories to be persisted via EF back to the DB.
4) ASP.NET MVC Application, this application talks to the service layer to get the objects it needs.
I like how this works as it provides a single point of interaction with the domain model, but what I think I need is a layer in between the service layer and the mvc application. The responsibility of this layer would be to transform domain objects to and from view models that the controller could interact with to get the exact data the view needs, and to provide the populated domain objects back to the service layer. Would this be the Application Service Layer and the service layer mentioned above is the Domain Service Layer?
I use AutoMapper to get the domain objects into view models, but I am not sure of the standard of getting them back to a domain object.
Any advice or ideas would be great.
While in theory, your Domain Layer (especially if you are using POCOs) classes are perfectly fine to use in Controllers and Views, in practice, there are always these corner cases and differences.
Typically, objects that controllers and views deal with are simplifications of your Domain Model POCOs or different aggregations of your POCOs from what your Application Service Layer provides/understands.
Therefore, I would not recommend building a separate layer and instead I would recommend adding methods to your View Models to your Domain Layer objects to be sent to your Application Service.
For example, if you have User Domain Level class and UserModel View Model, I would advocate creating User ToUser() instance method on and UserModel UserModel.FromUser(User user) static method to deal with conversion.
You can also mix and match other View Models in there to be able to create Domain Objects.
I haven MVC app, with "M" including Service and Repository layers.
However, I am a little confused as to where and how to do a couple of things.
One Service calling two repositories, or calling it's own repository and another service
e.g.
I have a ReferenceDataService, which handles all of the logic for CRUD with my reference tables.
Then in my "CustomerService" I need to 'R' my reference data to get e.g. Description instead of Id. So, do I call the ReferenceDataService or ReferenceDataRepository?
At some layer I'd like to map from Entity to ViewModel.
Do I do this in my Service layer, or in the Controller?
e.g. Does my ServiceLayer do the mapping/logic from VM to Entity and back?
Thanks:)
Repositories talk to an underlying data source.
Service layer talks to repositories with domain models. It takes/passes domain models from/to the repository layer.
Controller talks to service layer. Controller takes/passes domain models from/to the service layer.
Controller calls mapping layer (if any) to map between the domain models and view models. If you don't have a mapping layer you could do the mapping in your controller although this could quickly become cumbersome in which case AutoMapper could serve as a very handy mapping layer.
Another more simpler scenario is when you don't need a service layer which is often the case in smaller applications. A service layer brings no benefit. So the controller talks directly to the repositories with the domain models.
ViewModel contains data, required for displaying model on view. If you'll use another view (e.g. mobile application, or desktop application, or even web service) you will require another data to be displayed on view. If you'll do mappings on service layer, then you will not be able to use it with another type of application. Thus controller is a place where you map domain data to display them on view (whatever type of view you have).
We are building an ASP MVC3 application, where we are building the service layer and Entity model. A third party is building Views/Controllers.
Now the tricky bit is the Model. Where should it go?
My opinion is the MVC web application will just have View and controller. Our service library will have business logic and EF. But I think we should not expose EF entities directly to the web application. (or should we? ) Instead we should look at the views and create view model classes for each views. This might require creating multiple view model classes for each view.
Can anyone provide their opinion on if this is right design? If so, where should view models reside? should we create another library just for view models?
I would suggest making your models as POCO objects with CRUD functionality- you shouldn't expose the EF entities. This way your service library can be reused in other applications or interfaces if needed.
If the POCO objects you provide won't work directly as view models, then it's up to the team writing the controller to create a view model from your service objects (POCOs). That would probably (hopefully) be a very simple view model, using your POCOs as properties (maybe a view model is a list of one of your POCOs, or a combination of a couple different POCOs).
That's just my two cents...
I'm trying to architect my MVC web project and I'm running into a bit of a problem.
I am using EF4.1. I've created a DataAccess project with the EDMX file. Then I use the dbContext generator to make my POCO .tt classes.
As it is right now, my Business logic layer can access the POCO classes just fine, but the presentation layer cannot.
I think that I'm supposed to create another level of abstraction and put the dbContext .tt files into their own project so that both the BusinessLogic layer and the Presentation layer can access the POCO classes, but only the BusinessLogic has access to the entity framework. The presentation layer shouldn't need to know anything about EF.
Something like this...
POCO Classes - DataAccess
| |
|---------Business Logic
| |
|_________Presentation
Am I on the right track here, and if so, do I simply cut/paste the .tt files into the new project or is there a way to force the dbContext add-on to create these in my other project?
Your presentation layer doesn't have to know anything about the EF. Just reference that project from your presentation layer to access the models.
However - your presentation layer shouldn't ideally be using any of those POCO models. They should be using ViewModels. I dont necessarily believe in the DTOs here as DTOs have a specific purpose. Your repository/data access can return models but generally those get returned to a service layer. The service layer then would return your ViewModel representation to your controller.
This sets you up nicely for dependency injection as well, since into your controller you just inject your service layer. Into your service you can inject then any repositories you need, and so on.
Ironically I think I may be working on a book for this exact subject shortly : )
Consider sending Data Transfer Objects between your Business Logic and Presentation layers. This would allow you to shape the data for your views and and prevent information from leaking into the Presentation layer (e.g. if you have a field in your POCO that is needed for your business logic but doesn't need to be available in your Presentation layer).
The question is, how would you move data to and from the
presentation layer? Put another way, should the presentation layer
hold a reference to the domain model assembly? (In an Entity Framework
scenario, the domain model assembly is just the DLL created out of the
EDMX file.)
From a pure design perspective, DTOs are a solution really close to
perfection. DTOs help to further decouple presentation from the
service layer and the domain model. When DTOs are used, the
presentation layer and the service layer share data contracts rather
than classes.
A layer of DTOs isolates the domain model from the presentation,
resulting in both loose coupling and optimized data transfer.
If you go this route, also check out Automapper to help with mapping your DTOs to POCOs and vice-versa.
So there are several ways to structure your project. What you are referring to is one way, in which you share poco's between all layers.
Another way is to have your POCO's be in the data and business layer, then create a similar object model that's shared between UI and business layer. Finally, you might also create a third model for the UI only called teh ViewModel.
It all really depends on your needs. If your object model is very complex, then you might need to simplify it with ViewModels.