Asp Net MVC, гд лучше размещать запросы к БД?

Question

[Matsun]

В рамках обучения делаю свой блог на Asp Net MVC. Для работы с БД используется Entity Framework, подход Code First.
Вопрос вот в чём. Когда то слышал, что при разработке веб сайтов на MVC, запросы к БД размещать в контроллере не годится.
Соответственно тогда вот в чём вопрос, вот мой контроллер

public ActionResult ShowOne(string url = null)
        {
            Article one = repository.Articles
                    .FirstOrDefault(p => p.Url == url);

            one.FullText = Article.CreateTable(one.FullText);

            return View(one);
        }

Этот контроллер извлекает статью из БД с заданным URL.
Далее с помощью статического метода public static string CreateTable(string strStartText) (он расположен в модели предметной области) он обрабатывает текст статьи, вытягивая из него заголовки h2 и создавая на их основе оглавление.

Вот вопросы.
1. Надо ли переносить запрос к БД в модель, если да, до в какую, в модель представления или модель прдметной области? Просто тут у меня сомнения. Ведь модель предметной области представляет собой сущность статьи (подход Code First) и будет ли правильно, что помимо свойств, в модели будут ещё и методы?

2. Правильно ли метод public static string CreateTable(string strStartText) делать статическим и пумещать его туда же, есть ли более "элегантные" способы обработки полученных из бд данных?

Comments

[Толстый Лорри]

www.smarly.net/pro-asp-net-mvc-4/introducing-asp-n...

Answer 1

[Толстый Лорри]

Обычно приложения делят на три слоя:

• Data Access Layer
  
• Business Logic (Domain models)
  
• UI (Web).
  

BL независим, DAL зависит от BL, UI зависит от DAL и BL (ибо там располагается интерфейсы биндятся на реальные классы).

Если мы рассматриваем классическую схему доступа к данным через репозитории, то:

BL содержит: доменные модели, интерфейсы для репозиториев, сервисы (интерфейсы и реализации, которые работают с репозиториями).
DAL содержит: реализации интерфейсов репозиториев (из BL), т.е. работу с DB, DbContext (от EF) и прочую конкретику о том, откуда и каким образом извлекаются данные.
UI (для ASP.NET MVC) содержит: собственно веб-проект с котроллерами *Controller.cs (Controllers), вьюшками *.cshtml (Views), вью-модели *.cs (Models, те специфические модели, которыми типизируются вьюхи, они могут отличаться от доменных (маппиться с них в контроллере), например, содержать объект с данными пагинации).

Также UI сожержит корень внедрения зависимостей, где связываются между собой интерфейсы и их реализации, например, интерфейсы репозиториев из BL и реализации (заточенные на работу с БД) из DAL.

Пример реализации.

ЗЫ Азы такой архитектуры применительно к ASP.NET MVC есть в замечательной книжке Фримана.

Comments

[Matsun]

По поводу книги Фримна, сразу скажу, что я счастливый обладатель 5го издания в печатной форме, и в данный момент постигаю азы ASP MVC именно по ней. Для меня эта книга - просто находка.
Но всё же, на некоторые вопросы я там не нашёл ответ (или может быть пока не нашёл, так как нахожусь сейчас на 18 главе (Фильтры). Делаю свой блог именно по предложенной в книге модели.

Правильно ли я понимаю, что в принципе запрос repository.Articles .FirstOrDefault(p => p.Url == url); можно поместить в DAL (вы написали, что манипуляции с БД размещаются именно там). Но почему тогда Фримен в своём приложении SpotsStore так не делает, и размещает все запросы к БД прямо в контроллерах?

Ещё вопрос по поводу BL, я так понимаю что все сущности, которые там находятся должны иметь только лишь свойства? Метод CreateTable там размещать будет не правильно?

Вы пишите:
> BL содержит: доменные модели, интерфейсы для репозиториев, сервисы (интерфейсы и реализации, которые работают с репозиториями).

т е тут и может быть размещён запрос на извлечение записи из БД?


Также Вы пишите:
> UI (для ASP.NET MVC) содержит: собственно веб-проект с котроллерами *Controller.cs (Controllers), вьюшками *.cshtml (Views), вью-модели *.cs (Models, те специфические модели, которыми типизируются

Т е это и есть модели представления? (У Фримана есть такая - ProductsListView). А в эту модель я могу запихнуть свой метод - CreateTable

[Толстый Лорри]

Matsun: Ах, да, у Фримана же репозитории IQuerable возвращают) Это неправильно.

> т е тут и может быть размещён запрос на извлечение записи из БД?
Нет. Вы не знаете, какой ORM (например, EF) будете пользоваться завтра. Какой СУБД. Или вообще откуда брать данные. Может будет другой микросервис или Elastic Search. Поэтому хорошо было бы изолировать конкретный способ доступа к данным в DAL, создав абстракцию в виде IRepository.

> Т е это и есть модели представления?
Да.

> А в эту модель я могу запихнуть свой метод - CreateTable
Нет, ее задача - донести данные до представления. Откуда они берутся и как хранятся - это уже задача контроллера позвать некий сервис из BL, который позовет репозиторий из DAL, который уже знает, нужно ли ему создавать таблицу или, скажем, файл.

Как говорится, меньше знаешь - крепче спишь =) Изолируя слои между собой, вы уберегаете себя от "эффекта бабочки", где маленькое изменение в одной части кода рушило бы все к черту на другом конце. И протестировать вам достаточно этот маленький кусочек, а не всю программу во всех возможных режимах, снова и снова.

[Толстый Лорри]

Matsun: добавил пример реализации в ответ.

[Matsun]

большое спасибо, теперь хоть какое то понимание пришло.

[Matsun]

Толстый Лорри: огромное спасибо за пример.

Судя по нему, свой метод, который модифицирует текст статьи CreateTable, я бы мог поместить в класс "BlogPostRepository", который находится в DAL. Плюс в том, что его экземпляр и так и так будет создаваться в контроллере, и его легко использоваться

Но также есть сомнения, не правильнее ли будет такие специфичные методы обработки перенести с Business logic?, ведь вы пишите что там могут находиться сервисы и их реализации? " сервисы (интерфейсы и реализации, которые работают с репозиториями)"
Или вы подразумеваете что то иное под сервисами?

[Толстый Лорри]

Matsun: Пожалуйста.

> метод, который модифицирует текст статьи CreateTable, я бы мог поместить в класс "BlogPostRepository", который находится в DAL

Если таблица постоянная, метод предполагается вызывать один раз (при деплое приложения на сервер) и вы используете EF Code First, то лучше бы его и заюзать. Нужно как-то заранее продумать, как вы будете мигрировать данные при изменении структуры БД. Можно использовать миграции EF, но лучше бы с этим заранее познакомиться. Хотя можно и руками писать update-скрипты, тогда вся эта кухня будет у вас под контролем.

> не правильнее ли будет такие специфичные методы обработки перенести с Business logic?

Верно, вы это хорошо заметили, бизнес-логика должна находиться в BL. Для какой-то специфической обработки данных нужно создавать сервис (BlogPostServeice или как-нибудь так) в BL, в который инжектися репозиторий (через интерфейс, само собой), как источник данных, и уже этот сервис прокидывать в ASP.NET-контроллер. Сервис представляет собой некоторый логический модуль в терминах нашей прикладной области, поэтому он может использовать несколько репозиториев.

Сложный момент здесь вот в чем: как понять, поместить какую-то логику в репозиторий (DAL) или в сервис (BL)? Тут решается так: репозиторий должен быть максимально глупым, его задача - генерить SQL (или общаться с DbContext, в случае EF). Если мы хотим делать какие-то хитрые вычисления на стороне БД, то делаем специальный метод в репозитории (вызов к нему из контроллера можно просто прокинуть через сервис). Если же мы просто выкачиваем данные, а потом делаем с ними какие-то бизнес-преобразования, то их лучше унести в сервис.

Где делать логику: в базе или в приложении - это зависит от кучи факторов (использование ресурсов конкретным запросом, удаленность сервера с БД от сервера с приложением и прочее), решать нужно на месте.

[Толстый Лорри]

Matsun: то есть что-то вроде GetProductsByCategory лучше оставить в репозитории, а GetProductPricesWithDiscount (получить продукты с учетом скидки, т.е. модификация сущностей из базы каким-то бизнес-правилом - скидкой) лучше убрать в сервис, где сначала из репозитория вытащить интересующие продукты, затем получить скидку для пользователя, применить ее к этим продуктам...

[Matsun]

Толстый Лорри:
"а GetProductPricesWithDiscount (получить продукты с учетом скидки, т.е. модификация сущностей из базы каким-то бизнес-правилом - скидкой) лучше убрать в сервис"

Ох спасибо за вашу неоценимую помощь, сам бы я это искал бы ещё очень долго.
Попробую собрать в кучу то что вы мне подскали и свои соображения. На примере, что вы привели с продуктами.

Получается так:

ПРОЕКТ Product.Domain
BL:
- В папке "Entities", создаём сущность Product, со свойствами (Id, Price, Name).

- В папке "Abstract" создаём интерфейс IProductRepository, со свойством IEnumerable Products { get; }

- (вот тут сомнения, так как у Фримана её нигде не было) Создаём папку "Services", в ней класс ProductService с методом "public IEnumerable GetProductPricesWithDiscount(IEnumerable list)"
вроде с бизнес логикой всё

Далее
DAL
- В папке создаём "Concrete" класс контекста
public class EFDbContext : DbContext
{
public EFDbContext() : base("name=EFDbContext") { }
public virtual DbSet Products { get; set; }
}

- Здесь же создаём файл и реализуем интерфейс
public class EFProductRepository : IProductRepository
{
private EFDbContext context = new EFDbContext();

public IEnumerable Products
{
get { return context.Products; }
}
}

Проект Product.WebUI Слой UI:
- В папке Controllers создаём

public class ProductsController : Controller
{
IProductRepository repository; // создаём экземпляр с помощью инъекции зависимости
ProductService productService = new ProductService(); // сразу инициализируем, чтобы иметь возможность в экшене использовать скидку на товар

public ActionResult List()
{
IEnumerable productList = repository.Products;
IEnumerable productListDiscount = productService.GetProductPricesWithDiscount(productList);

// ну а далее собираем все данные в модель представления и передаём во вьюху
}
}

Ну что скажите? Правильный ли ход мысли?

[Matsun]

Толстый Лорри: Хотя я не совсем внимательно прочёл ваш этот абзац:

" Верно, вы это хорошо заметили, бизнес-логика должна находиться в BL. Для какой-то специфической обработки данных нужно создавать сервис (BlogPostServeice или как-нибудь так) в BL, в который инжектися репозиторий (через интерфейс, само собой), как источник данных, и уже этот сервис прокидывать в ASP.NET-контроллер. Сервис представляет собой некоторый логический модуль в терминах нашей прикладной области, поэтому он может использовать несколько репозиториев."

Если учитывать то что вы написали, то получается надо исправить то что я написал постом выше.

1. Во-первых, Создать интерфейс для ProductService
2. Убрать из контроллера внедрение DI - IProductRepository repository, вместо неё добавить новую DI,
IProductService productService.
3. Добавить в проект Product.Domain зависомость в класс ProductService экземпляр IProductRepository repository.
4. Метод контроллера public ActionResult List() изменить на
public ActionResult List()
{
IEnumerable productListDiscount = productService.GetProductPricesWithDiscount();
// все данные GetProductPricesWithDiscount будет брать сам из репозитория, который подключается c помощью DI
}

Так будет правильнее? А пример посто выше имеет место быть? Или это котровенный говн*кодинг?

Очень прошу прочитать два моих последних коммента, обещаю после этого отстать =))))

[Толстый Лорри]

Matsun:
1 - верно
2 - верно и в сервис (в конструктор) нужно инжектить репозиторий. IoC-контейнер автоматически подтянет все необходимые зависимости зависимостей.
3 - Domain (который BL) не должен ни от кого зависеть, это такая рафинированная бизнес-логика в вакууме.
4 - верно

Конечно, это пока размахивание руками в воздухе. Если сделаете проект, зальете на какой-нибудь гитхаб/битбакет, смогу поревьюить и может дельное подсказать.

[Matsun]

"Конечно, это пока размахивание руками в воздухе. Если сделаете проект, зальете на какой-нибудь гитхаб/битбакет, смогу поревьюить и может дельное подсказать."

пока мой код стыдно куда то выкладывать =)) там будет ошибка на ошибке, ибо ко мне только сейчас начало приходить минимальное представление об ООП и MVC

Спасибо, за такую неоценимую помощь!