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...
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 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?
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.
I am new to MVC2 and having a little problem with implementing validation via buddy classes.
I am using Repository pattern with dependency injection.
My Entity Object Model is in Data Layer Project and Buddy Classes are in Business Layer project and MVC 2 Project as a separate Presentation Layer Project.
Can any one help me out with implementing Buddy Classes in this Architecture?
Partial classes work only within the same assembly. So you have two possibilities: define validation rules in the same assembly as your model classes or don't use DataAnnotations. As an alternative you may take a look at FluentValidation allowing you to define validation rules in a separate assembly and which has a great integration with ASP.NET MVC as well.
As far as the views in your MVC project are concerned they should never work with your model classes. You should define view model classes which are specifically tailored to the needs of each view. The controller will then perform the mapping between the models and the view models. AutoMapper could be used to ease this task. So basically all user input like required fields and datetime formats should be validated at the view model and business rules at the service layer.
I've been using ASP.net MVC for about two years now and I'm still learning the best way to structure an application.
I wanted to throw out these ideas that I've gathered and see if they are "acceptable" ways in the community to design MVC applications.
Here is my basic layout:
DataAccess Project - Contains all repository classes, LINQ-to-SQL data contexts, Filters, and custom business objects for non-MS SQL db repositories (that LINQ-to-SQL doesn't create). The repositories typically only have basic CRUD for the object they're managing.
Service Project - Contains service classes that perform business logic. They take orders from the Controllers and tell the repositories what to do.
UI Project - Contains view models and some wrappers around things like the ConfigurationManager (for unit testing).
Main MVC Project - Contains controllers and views, along with javascript and css.
Does this seem like a good way to structure ASP.NET MVC 2 applications? Any other ideas or suggestions?
Are view models used for all output to views and input from views?
I'm leaning down the path of making view models for each business object that needs to display data in the view and making them basic classes with a bunch of properties that are all strings. This makes dealing with the views pretty easy. The service layer then needs to manage mapping properties from the view model to the business object. This is a source of some of my confusion because most of the examples I've seen on MVC/MVC2 do not use a view model unless you need something like a combo box.
If you use MVC 2's new model validation, would you then validate the viewmodel object and not have to worry about putting the validation attributes on the business objects?
How do you unit test this type of validation or should I not unit test that validation messages are returned?
Thanks!
Interesting.
One thing I do differently is that I split off my DataAccess project from my Domain project. The domain project still contains all the interfaces for my repositories but my DataAccess project contains all the concrete implementations of them.
You don't want stuff like DataContext leaking into your domain project. Following the onion architecture your domain shouldn't have any dependencies on external infrastructure... I would consider DataAccess to have that because it's directly tied to a database.
Splitting them off means that my domain doesn't have a dependency on any ORM or database, so I can swap them out easily if need be.
Cheers,
Charles
Ps. What does your project dependency look like? I've been wondering where to put my ViewModels. Maybe a separate UI project is a good idea, but I'm not entirely sure how that would work. How do they flow through the different project tiers of your application?