I am creating an Simple Application where A user register his/her name and After Registration he/she Redirect to Login Page ang after login he/she redirect to the Home page.
A Simple Application as i said..
But My concern is that I want to Implement this In MVC3 But using 3-tier Architecture.for this I created A MVC3 Project named it as Presentation and Created a New Project under Solution and named it as DAL and Shifted the Model Folder in DAL where i have created all the Properties and DbContext and Controller and View in Presentation.So can any one tell me what to keep inside BLL Folder?Please Suggest me!!!
One solution would be to use MVC as a Presentation layer (as you are doing it right now). Inside of your MVC there will be cases when a model would not be sufficient for you in which case you will need to create ViewModels. You can move the ViewModel to the business layer in which case when BLL retrieves data from DAL, it converts it into some ViewModel with some functionalities and defaults, and send it over to the presentation layer. Once the presentation layer finishes with using the VMs, it passes the data to the BLL which can perform some special validation and some extra business logic. After that it would create model(s) by extracting data from VM and pass it to DAL which can perform transactional update, delete or insert.
Normally my solution at minimum has five projects. I have API project, MVC, Business Layer, Data access layer and Resources.
API
This project contains models, interfaces, abstract classes, etc. In essence it contains everything that other layers need to implement. There is usually IRepository for the Repository Pattern implementation, IUnitOfWork for the Unit of Work pattern, models which are either generated by Entity Framework or by hand (but no mappings). ViewModels are also here together with extension methods for converting to and from the models.
Business Service Layer
This layer is in charge of fetching the data from the data access layer, converting it to the view model by invoking extension methods, initializing values. Also, if a DAL returns null value, the business service layer will not pass it over to the presentation layer as null, but will return an implementation of the Null Object Pattern. The Null Object Pattern is actually implemented in API and is called by business service layer. This layer references API layer.
Data Access Layer
Here you normally implement the repository and unit of work patterns. Instead of directly communicating with EF, you would wrap calls to DbContext into these two implementations. In addition to this, mappings from models to SQL Server tables and columns, as well as foreign keys are done here. This layer references API layer.
Resources
All the resources, strings, language translations, etc are located here. This project does not reference API, but Business Service Layer, Data Access Layer and Presentation Layer reference this project to get access to the strings.
Presentation layer
This is normally an MVC solution (or if it is Web Forms then there it will be implemented using MVP patter). This solution communicates with Business Service Layer. It receives ViewModels and return values from the business layer. It passes the view models if they are valid to the business layer in order to have them persisted.
Linking layers
The layers are connected among themselves using dependency injection. I usually use Unity and configure my application using external configuration settings. This way the Presentation layer, business service layer and data access layer do not have explicit reference. MVC does not hold a direct reference to BLL, BLL does not have a direct reference to DAL. The constructors for controllers and BLL and DAL classes use interfaces and unity passes the appropriate implementation.
You will probably put any Helper methods, Library code or re-usable business logic that the that the controllers use. I often put utility classes and validation logic in here plus any functionality that works with the data obtained from the DBContext Entities.
Related
My understanding of Spring MVC is that the View layer is responsible for the user interface that is populated with data, the Model represents a Map of values made available to the View Layer, and the Controller controls how and what data is passed to the Model as well as what business logic is carried out. The "business logic" can be divided into one or more other layers - generally a Service layer and/or Data Access layer. Is this correct?
I've seen other explanations for the MVC pattern where the Model is considered a layer with Entities, Data Access Objects, and Services. The View is responsible for the user interface. And the Controller is the gateway between the two. I don't think this applies to Spring MVC and other implementations of MVC for web frameworks.
Your understanding as outlined in the first paragraph is mostly correct. Where I differ slightly is in viewing Model, View and Controller as separate layers of an application (since you have references to View layer). MVC is a pattern for implementing user interfaces, which would typically be part of a Presentation layer in an application. There are other patterns for implementing the presentation layer such as MVVM, MVP, PAC, and so on besides MVC.
Spring MVC is built on top of the Spring framework. If you are familiar with the Spring framework you would know that it is one of many available Dependency Injection frameworks for Java. Spring MVC Controllers are regular Spring managed beans that can be discovered by the Spring DI container and can have other Spring beans injected into them.
Model objects in a Spring MVC application can be instances of any Java class, whether in-built data types such as String, Long, BigInteger, etc. or user-defined classes and enumerations.
Views can again be anything meaningful for an end-user - an HTML page, an XML document, a JSON document, a PDF document, an Excel spreadsheet and so on. Spring MVC does not provide any view generating mechanism out-of-the-box. However, it makes available integration to several existing view generation technologies, such as, regular JSPs, JSTL, templating engines such as Freemarker, Java, Thymeleaf and StringTemplate, reporting frameworks such as Jasper Reports, XML binding frameworks such as JAXB and Castor, JSON binding frameworks such as Jackson and GSON, and so on. The Spring MVC API is fairly easy to integrate with view generation technologies and therefore the framework can accommodate new technologies relatively easily.
Since Spring MVC is a presentation layer framework, it does not specify, recommend or enforce how business logic should be implemented. However, it is generally a good idea to keep the business logic out of the presentation layer (see SOLID principle for details). For example, if you wish to provide certain users or business partners programmatic access to your business logic, you would be better off having the business logic in a separate layer of its own which the web presentation layer would invoke. You could then create a thin layer that also invokes the same business logic layer and allows programmatic access to external users using data interchange mechanisms such as SOAP, REST, EDI, etc.
MVC is the UI layer.
A model is a map of objects, representing data for your views. These objects often are JPA entities, but don't have to be. It could be a simple class representing a username and password in a login form.
Keep some logic in model classes. For example, if you want to calculate the interest rate on a loan, you could do this in a model class. For complicated logic, especially when multiple model classes are involved, use a service.
Model classes must be completely independent of views and controllers, in that they can exist without them.
A controller responds to HTTP requests. Generally it is responsible for loading the correct models and choosing the correct view, and returning this info. Controllers should be pretty dumb.
You want "fat models and skinny controllers". Keep as much logic in the model as you can.
A view is a JSP or template (like Thymeleaf or Freemarker) which can consume models. The trick is to have as little logic in a view as possible.
I am implementing 3-tier architecture. I just wanted to know the role of business layer
in 3-tier architecture.
I am developing application in using entity framework. So I have entity object which is
accessiable in PL,BL & DL. My question is whether input assignment to entity object should be
in PL OR BL.(Consider there is save method)
Business layer is the class where we write the functions which get the data from the application layer and passes through the data access layer.
I think, you have read about layered architecture. You can refer to the details on Microsoft's site: http://msdn.microsoft.com/en-us/library/ff648105.aspx
As the name suggests, business layer contains all business logic implementations. The presentation layer just calls up services in the business layer or invokes assemblies (DLLs) of the business layer and passes on the input.
Let me know what kind of application you do have. That will enable me to provide some more contextual information.
So I'm assuming people still use a business layer outside just controller logic? If so where's that grey line drawn and what do you not put in your controller classes that you would in your Business Layer project and vice versa? Seems to me like Controllers rid the need for a business layer in your MVC application totally.
The controller layer is part of the view, in my opinion. What you're calling the business layer I call services (not web services; that's just one deployment choice among many).
The business layer knows about use cases and units of work for accomplishing the objectives of users.
The controller is all about validating, binding, and marshaling requests, determining which service is needed to fulfill the request and passing values to it, unmarshaling the response and routing it to the next appropriate view.
So I agree with the hypothesis posed in your title: controller != service.
The classic pattern that came from Smalltalk is Model-View-Controller, which disagrees with my statement by breaking view and controller into separate tiers.
What I'm describing is what is implemented in Java frameworks for both web and desktop. A change in view technology generally means changing the controller as well.
So if the Smalltalk idiom was model-view-controller, the more modern approach would look like view->controller->service->model/persistence. Model means "domain objects", which are independent of all view technologies.
The line is not "grey". It's stark and absolute.
The model (or "business layer") works with any presentation. GUI, command-line, web. And it doesn't require any changes to be wrapped with a GUI (view+control) a Command-line application or a web application.
You know you've done the model ("business layer") correctly when there are no presentation or control features in at all. Further, it's so complete that any GUI can use it directly.
To put it simply:
Controller should contain the application specific logic.
"Business Layer" should contain the business logic.
Following Eric Evans' Domain Driven Approach, the "Business Layer" contains:
Service tier: the interface is designed around the use case scenario
Domain Models: the core domain objects, entities, value objects and more.
Data Access objects: repositories
Also note that the Domain models is not the Data Access tier. It might encapsulate data access, but is not the data access tier itself.
We have a decent sized MVC project running well at the moment, i've started to look at some re-factoring and I have a question.
At the moment the Data Layer and Service Layer is stored in a seperate class library. The controllers load the data objects (generated from linq2sql) from the service layer which does any logic check and then converts them to viewmodels (Using Auto-Mapper).
Instead of this should the ViewModels be returned directly from the service?
Definitely not!
A ViewModel's purpose is to mediate between the view and the 'real' data objects - it's totally view-specific. So layers other than your GUI shouldn't even know that such a model exists, if you want to keep a clean separation of concerns...
I would say not. The point of the service is that it can be used by many different projects that deal with your business layer. I would expect this to be in terms of your business objects. View models are specific to an MVC application and, thus, I would expect them to be separate from the service layer. Note that they often encompass both business and "housekeeping" data for the application, and may encapsulate multiple business objects. I think I would continue to transform them in your controller.
So we are building an application with a
UI Layer (web, mobile, Ajax client, etc)
Service/API Layer
Business Logic Layer
Data Access Layer
Our goal is to have an Entity Framework dependency from the Service Layer on down to the DAL. That means the Sevice layer will only accept and return POCOs (plain old CLR objects).
What we're currently doing is manually coding a mapping layer between the service layer and business logic layer that will convert POCOs to EF Entities and vice versa.
So in short, page has form, form has codebehind that takes form contents, stuffs them into a POCO, sends it to service layer. Service layer converts to EF Entity, sends it to Business Logic Layer which performs certain transformations to the entity, and then interacts with the DAL to get it persisted.
Yes, its a bit tedious, but we were wondering if theres a better way?
Yes, I know someone published an EF Poco Adapter but it's all in C# and we would prefer a VB.NET solution.
Yes, Switching to NHibernate is an option of last resort, as we are already deep into our development cycle.
You should be performing business logic on POCOs. The entire purpose of ORM is that it is an implementation detail. The business logic should be implemented in the domain model and in the domain services - in a business application, "domain" means "business". The DAL should be there to take a POCO and persist it - in your case, that means mapping it to and persisting an EF entity.
That's the theoretical / NHibernate model, at any rate.
Can you stand having a dependency in the service layer on the EF interfaces? You could implement IPOCO.
There's even a way to do it automatically.