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.
Related
I have been jumping between articles and questions but i can't seem to find the information i want.
When i started learning about MVC, tutorials and articles pointed out that:
*Models: is where you business logic goes
*Controller: is where data-access and handling request/respond happens.
I have been working with MVC for a while now and I wanted to migrate an old simple project to MVC. In the project i have a business and data access layers.
After reading about N-Tier MVC architecture, my understanding changed.
The model in which i usually presumed to be the business domain has now changed to be more of a presentation depending on views. Its true that models reflects the business entities but it acts as another layer over it.
So my question here is the following: Assume that i have an MVC project and i have another two projects, business and data-access. Is the relation in this manner right ?
*A model, will mostly have the same properties as in its corresponding business entity.
*The controller will call the DataAccess-Layer to retrieve data, the data will be returned as business object which will be mapped into a model and then returned into a view.
Model not always corresponds to business entities. Because models in MVC used to reflect entities that will be sent to view. So they may be little bit sipmlier than domain business entities. It is correct that your domain model will be mapped to mvc model.
Second statement I agree 100%.
Is the relation in this manner right ?
My answer is that depends on your project scale and team size, But let me explain you my projects architecture.
MVC: A presentation layer, It is the startup project of the application.
Common: This is a class library which contains a set of core classes, such as helpers, base classes, ... This project is referenced to all other projects.
Repositories: For reading from and writing to a database, I've created a project and named it repositories. This project is a combination of repository and the Unit of Work pattern. Implementing these patterns can help insulate your application from changes in the data store.
Test: Unit tests are written in this project.
Hope this will help you.
I currently have a web application that is based upon a 3 Tier architecture. I wish to change my Presentation layer from using Web Forms to MVC4.
Now I have done some research and from what I read I understood that the View represents the .aspx of a Web Form. The Controller represents the Code Behind (.cs) of a Web Form.
The problem that I have is that I do not see any use for the Model. This is because I can directly call methods from the Business Logic Layer directly from the Controller making the purpose of the Model useless.
Is there something that I am misunderstanding? If so what are you views on implementing an MVC design patter for the presentation layer in a 3 layer architecture?
In a simple application the model in MVC can simply be the DTOs from the Application or Business Layer. In this case you're right, you probably don't need a separate model in the UI.
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.
Both of them are based from mvc.
But in 3-tier architecture,storage layer is a separate layer,
while in symfony framework,database(storage) level is included in model layer.
Why are they different?
I would say that MVC is focused on user-interaction. It describes how to develop a rich and flexible system that reacts to user requests, but says nothing about what happens below controller layer.
It just says:
user sends a request;
dispatcher forwards request to appropriate controller;
controller retrieves models, but it's not specified HOW: using model's methods, using a DAO layer, using a Managers layer, whatever;
controller forwards to a view.
CakePHP also has model and data layer glued together, as many others. It's just a choice: this way you have less layers and less code, but in case you change your mind you'll have to modify all your code, directly in the models.
I'm making my way through the early Data Access Tutorials on Microsoft's ASP.NET website and it occurred to me that this all seems awfully similar to what I have read about separating your logic and presentation code using the MVC pattern. As a newbie I have yet to implement the MVC pattern but I'm curious as to how these two design structures differ and if I should be focusing my attention on one or the other, particularly in the context of web design.
MVC addresses more than just data access. In MVC, both the DAL and BLL is incorporated into the Model. The view defines how the model data is presented to the user, while the controller is what responds to user inputs (GET/POST on the web).
An alternative to MVC is a classic N-tier architecture where you have a presentation layer, a business layer, and a data access layer. In this architecture, the components of the view and controller are wrapped together in the presentation layer. WebForms/WinForms is an example of the N-tier architecture, while ASP.Net MVC is an example of MVC in the Microsoft space.
The link you've posted for the Data Access Tutorial is implementation of MVC pattern. MVC pattern is a concept, implementation can differ; you have this in ASP.NET whereas in Java there's one framework called Struts, which is an implementation MVC.
DAL & BLL patterns differ from the MVC pattern in terms of concepts; but NOT this specific implementation. MVC is actually achieved through usage of DAL, BLL & View Patterns.