2

Based on the answers mentioned here, I understood that I should put the business logic inside the model itself, while in my program I am using EF directly inside the actions of the controller for example to get the list of cars from the database directly I am doing the following:

public ActionResult CarList()
{
    using(var _db = new CarRentEntities())
    {
         var result = _db.Cars.Where(m=>m.Active);
         return View(result);
    }
}

what is the impact on my website performance if I will use the mentioned above code inside controller or inside Model?

which method I should use? for example if I want to work with a team, is there a standard I should follow to separate the code, kindly advise

for using the repository pattern: I read that we should not use if as mentioned for example here , i will copy some of what mentioned:

The single best reason to not use the repository pattern with Entity Framework? Entity Framework already implements a repository pattern. DbContext is your UoW (Unit of Work) and each DbSet is the repository. Implementing another layer on top of this is not only redundant, but makes maintenance harder.

if my database contains the following tables: Manufacturers , Cars , Rent , Clients , rent class is the a table with 2 foreign keys between Clients and Cars and contains other detailed fields.

how to deal with Rent Object which need to get data from 2 different repositories Cars and Clients in order to display the renting grid based on search criteria entered by the user, if I will use the repositories Cars and Clients , they have their own dbContext, BOOM my head cannot understand this technique, kindly advise

Community
  • 1
  • 1
user5135401
  • 218
  • 1
  • 9
  • 1
    This is basically a separation of layers concern. It isn't really about performance but more about maintainability. It your case: if your datalayer changes you'll might have issues in your ui-layer. Besides that: sending all your data from datalayer to ui might lead to security issues. You a re probably using a hidden field for ID's somewhere, which can be manipulated very easily ;-) – Stefan Jul 31 '15 at 09:25
  • 1
    you can read this article about factory pattern which is mentioned below in the answers: http://www.oodesign.com/factory-pattern.html , simply make a layer that you will put all of your methods that will use EF and models as containers and easily you can follow what @PhilipH mentioned, in this way, your models will stay clean and your controllers will be thin and your code will be more maintainable – Monah Jul 31 '15 at 10:08

2 Answers2

6

The answer to your question is, it does not really affect performance but it will definitely become an issue in terms of maintainability as the application grows bigger. You can adopt the SOLID architecture principles: SOLID architecture principles using simple C# examples. This enables you to develop high quality software.

You can create a multi-layered application:

  1. Interface Layer - MVC application
  2. Business Layer - Class Library with classes with logic
  3. Data Access Layer - Database Contexts and Repositories, unit of work with CRUD operations
  4. Shared layer - Logging, AppSettings, validations, utilities, extensions, constants, enums

Having your application in this structure would require you to consider things like inversion of control, dependency injection and many more to ensure loosely coupled classes, easy unit testing and most of all a solid application.

You can also read this: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application

Oluwafemi
  • 14,243
  • 11
  • 43
  • 59
  • I am reading now the SOLID article, about the repository, I read some articles that advising not to use repository at all, some ideas said that EF is already an repository structure, so if we will build a repository, then we are complicating our code – user5135401 Jul 31 '15 at 09:49
  • This is only applicable to EF but you can find yourself where you need to remove it to use ADO.NET. Now what would you do? – Oluwafemi Jul 31 '15 at 10:00
  • 2
    #user5135401 I agree that EF is a repository implementation, but of such openness that it can no longer function as a generic repository. Its clearly technically possible to implement a flat-file or in-memory XML store and have EF use it as its data store, but it would be a big task with a high likelihood of introduced defects. I personally don't use EF because its too coupled with the underlying database - I always use a business context specific data store factory+interface pattern and simply use ADO.net to call stored procedures (but you could use EF instead). – PhillipH Jul 31 '15 at 10:40
2

Generally the Model is a "unit" - i.e. it is a model of the data you want to display. The Controller is an "integrator" - i.e. it pulls together the various resources required to render your web page. You may wish to create a database fascade class which does something like this;

public ActionResult CarList()
{
    using(var carStore = new Factory.CreateCarStore())
    {
         var result = carStore.GetActiveCars();
         return View(result);
    }
}

To separate your database access from your web controller (this would make it more test-able as well because you can substitute a different CarStore implementation (i.e. a Test XML data set) for testing purposes.

PhillipH
  • 6,182
  • 1
  • 15
  • 25
  • thank you for your answer, kindly is there a reference or a sample code I can look for about your idea ( Factory , how it looks like)? – user5135401 Jul 31 '15 at 09:46
  • 1
    @user5135401 it's an implementation of the `Factory Pattern` see https://en.wikipedia.org/wiki/Factory_(object-oriented_programming) – 3dd Jul 31 '15 at 09:52