Reputation: 4053
I've already read some articles about this matter, but I'd like to ask once again because I'm not sure how to solve my problem.
I work on project in which we use MVC3. The project should manage school system (schools, pupils, teachers, parents, users, roles and so on. In the center of such a school management system is - schedule of subjects.
We get data from MS SQL Server through EF4 (database first approach), which means all entity classes are created automatically. Therefore, I have such a classes that represent database tables such as School, Pupil, Teacher, Role and so on. And I have DbContext derived class.
We primarily know how our presentation (UI) layer should look like.
The problem is in layer between UI and classes we got automatically by using EF4 that I've already mentioned. I've read about repository and unit of work patterns and understood how they work. I've thought we could apply those patterns, but our project architect wants to use something else. He wants to have clear separation of layers. He wants to call simple methods from controllers that are placed in business layer, which means almost whole logic should not be in controllers, but in that business layer.
I'm not sure now what I should start with. I have all those entity classes School, Pupil, Teacher, Role and so on. And I have DbContext derived class. That means those classes are input for business layer. What should be output of business layer? How could I design business layer?
Thank you in advance.
Goran
Upvotes: 0
Views: 1177
Reputation: 93424
You just create a business layer. Typically, this will be a new project in your solution. PROJECT.Business or PROJECT.BLL or similar.
This layer has classes that map to your domain, so you would create similar classes as Pupil, Teacher, School, etc..
You might have a School class, and that school class has methods like "GetStudents()" This GetStudents() method will then instantiate your Data layer, and return a collection of students. If you need to apply any logic, this is the place.
MVC is the UI layer. EF is the Data Layer. You create the business layer as you want, it's not part of either the MVC or Data layer, and is entirely up to you.
Upvotes: 2
Reputation: 82267
In my opinion you should have a repository for getting data to and from the database and querying. For operations where you are manipulating the data or preparing output, you could simply extend the classes you already have in your models to give that functionality. The business layer should be outputting data relevant for use in your views. This data can be requested in the controller via the repository, worked on by the extended classes, and then prepared in a strongly typed model for the view.
Upvotes: 0