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

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 to XML, WCF-вызовы удаленных ресурсов через Интернет, ...)

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

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

Answer 2

Ознакомьтесь с шаблоном репозитория

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/

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

Answer 3

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

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

Для примера, скажем, это приложение для выставления счетов; хранение клиентов, счетов и т. д. Ваша реализация будет отличаться, в зависимости от вашей стратегии доступа к данным (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
}