ASP.NET MVC Design Question - Где разместить код доступа к БД?

Question

Я играл с ASP.NET MVC последние несколько недель. У меня есть простое веб-приложение с формой, которая содержит несколько выпадающих списков.

Элементы в выпадающих списках хранятся в базе данных, и я использую LINQ to SQL для их извлечения.

Мой вопрос: где это место для размещения этого кода? Из того, что я читал до сих пор, кажется, что рекомендуется держать контроллер «тонким», но в этом случае у меня есть этот код, поскольку он должен выполняться при загрузке страницы.

Где я должен размещать код доступа к БД и т. Д.? Я включил выдержку из моего контроллера ниже.

Спасибо.

public ActionResult Index() 
    { 
     TranslationRequestModel trm = new TranslationRequestModel(); 

     // Get the list of supported languages from the DB 
     var db = new TransDBDataContext(); 
     IEnumerable<SelectListItem> languages = db.trans_SupportedLanguages 
      .Select(c => new SelectListItem 
       { 
        Value = Convert.ToString(c.ID), 
        Text = c.Name.ToString() 

       }); 
     ViewData["SourceLanguages"] = languages; 
     ViewData["TargetLanguages"] = languages; 
     return View(); 

Answer 1

Ваш код доступа к базе данных должен находиться в репозитории. Пример:

public interface ITranslationRepository 
{ 
    Translation GetTransaltion(); 
} 

и контроллер будет использовать этот репозиторий:

public class TransaltionController : Controller 
{ 
    private readonly ITranslationRepository _repository; 
    public TransaltionController(ITranslationRepository repository) 
    { 
     _repository = repository; 
    } 

    public ActionResult Index() 
    { 
     // query the repository to fetch a model 
     Translation translation = _repository.GetTransaltion(); 

     // use AutoMapper to map between the model and the view model 
     TranslationViewModel viewModel = Mapper.Map<Translation, TranslationViewModel>(model); 

     // pass the view model to the view 
     return View(viewModel); 
    } 
} 

Так основная идея заключается в следующем:

1. Контроллер запрашивает хранилище для извлечения модели
2. Контроллер сопоставляет эту модель с моделью просмотра (AutoMapper отлично подходит для этой работы)
3. Контроллер передает модель представления к представлению
4. мнение сильно типизированных к модели представления и использует его для редактирования/отображения

Что касается реализации этого хранилища касается не стесняйтесь использовать любой технология доступа к данным вам нравится (EF, NHibernate, Linq для XML, WCF вызовы к удаленным ресурсам через Интернет, ...)

Есть следующие преимущества:

1. логика контроллера полностью отделена отДоступ к данным логик
2. Ваши контроллеры могут быть протестирован в изоляции
3. ваши модели не завалены свойствами, которые должны принадлежать к слою UI (например, как SelectListItem) и, таким образом, могут быть использованы повторно через другие виды применения, чем ASP.NET MVC ,
4. Модель представления - это класс, специально разработанный для нужд представления, означающий, что он будет содержать определенные форматированные свойства, а код вида будет чрезвычайно читабельным.
5. Ваши мнения сильно типизированных => больше не ViewData и уродливые волшебные струны

Answer 2

Предполагают, что ваш код доступа к данным должен быть , содержащиеся в его собственном проекте/сборки. На это ссылается уровень пользовательского интерфейса (приложение ASP.NET MVC). Это поможет добиться того, чтобы ваши контроллеры были тонкие, и сохраните весь код доступа к данным из вашего проекта MVC UI.

Это типично приводит к другому вопросу/обсуждению объектов домена: при сопоставлении с хранилищем данных. Некоторые архитекторы любят иметь сущности в своей отдельной сборке. Это способствует повторному использованию в других приложениях. Некоторым нравится сохранять модель объекта и код доступа к данным в одном проекте/сборке. Это полностью зависит от вас и вашей среды.

Например, предположим, что это приложение для выставления счетов; холдинг клиентов, счета-фактуры и т. д. Ваша реализация будет отличаться в зависимости от вашей стратегии доступа к данным (ORM, например, LINQ To SQL, EF, nHibernate, SubSonic или простой старый ADO.NET или чтение из плоского файла).

// Assembly: InvoicingDL 
public class CustomerRepo 
{ 
    public IQueryable<Customer> ListCustomers() 
    { 
     return MyDatabase.Customers(); //however you'd get all your customers 
    }  
    //etc 
} 

// Assembly: InvoicingDL 
public class InvoicingRepo 
{ 
    public IQueryable<Invoice> GetCustomerInvoices(int custID) 
    { 
     return MyDatabase.Invoices.Where(i=>i.CustomerID==custID); 
    }  
    //etc 
} 

Answer 3

Отъезд Repository модель

https://web.archive.org/web/20110503184234/http://blogs.hibernatingrhinos.com/nhibernate/archive/2008/10/08/the-repository-pattern.aspx

http://www.mindscapehq.com/blog/index.php/2008/05/12/using-the-unit-of-work-per-request-pattern-in-aspnet-mvc/

Идея заключается в том абстрагироваться ваш доступ к данным в то, что называется хранилище, которое возвращает объекты домена. Затем ваш контроллер может использовать этот репозиторий для получения соответствующих объектов из базы данных и назначения их модели.