Где поставить функции, которые помогают мне выполнять задачи контроллера?

В настоящее время я работаю над проектом веб-сайта ASP.net MVC.

Я поместил весь материал, связанный с базой данных в моей модели, например запросы и функции обновления/удаления/сохранения.

Я также создал пару контроллеров, которые выполняют логику. Я добавил пространство имен Helpers, и внутри этого пространства имен есть несколько классов, которые содержат логику для разбивки на страницы, интернационализацию и т.д.

Мне было интересно, какая наилучшая практика для размещения функций и классов, которые выполняют некоторые общие вещи, например, создание счета-фактуры?

Ответ 1

Как я уже сказал в комментарии выше, я тоже очень заинтересован в этом вопросе.

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

Итак, я думаю, что я склоняюсь к следующей схеме:

Сделать действия контроллера очень маленькими; всего несколько строк кода.
Сохраняйте модель простой и, в основном, без функций и помещайте ее в отдельный проект.
Поместите все свой код, который выполняет всю "реальную" работу ( "бизнес-уровень" ) в отдельный проект.

Таким образом, вы получите полную свободу в выборе собственных пространств имен, вы сможете создавать любое количество полезных классов, функций и, как правило, структурировать свой код, как вам нравится, без ограничения ASP.NET MVC.

Это просто идея. На данный момент Im работает над моим первым большим ASP.NET MVC-приложением. Поэтому я действительно собираюсь узнать, как и как это работает на практике.

Ответ 2

Возможно, вы захотите создать некоторые сервисы, которые вы вводите в свои контроллеры.

Это почти слишком широкий вопрос.

Ответ 3

Такая бизнес-логика должна быть где-то в вашей модели.

Тем не менее, я нахожу, что когда есть что-то, что на самом деле не "подходит" где угодно - и у вас может возникнуть соблазн создать класс Utilities - это обычно хорошее место для использования методов расширения.

Возможно, вы можете добавить методы расширения в свой набор данных, чтобы помочь вам с разбивкой по страницам?

Ответ 4

Мне действительно нужна практика best, рассмотрим Domain Driven Design. Он не подходит для всех проектов и требует хороших навыков ООП, но я думаю, что это без сомнения "лучшая практика"... пока вы можете себе это позволить; -)

Обратите внимание, что вы уже нарушаете DDD, так как вы используете шаблон Active Record (поместите логику продолжительности в сущности). Итак, я не говорю, что у вас есть, чтобы следовать DDD. Но в любом случае это будет полезно.

Ответ 5

У меня есть классы модели, у которых есть Crud и Poco, как у вас.

Кроме того, у меня есть Viewmodels, которые используются для типизированных представлений.

Мои режимы просмотра довольно большие и используются в нескольких представлениях (около 10-15 моделей просмотра для всего приложения). В моем приложении эти ViewModels оказались идеальным местом для кода, который был сложен большим и повторным для действий контроллера.

Например, у меня есть некоторая логика, которая довольно близка к пользовательскому интерфейсу, когда я добавляю продукт в корзину. Теперь у меня есть метод в ViewModel: AddToCart (сервисной службы IProductService, сервисной службы ICartService).

Ответ 6

Я думаю, что лучшим решением этого вопроса о практике является: Поместите логику в Модель, если она будет использоваться через контроллеры. Если контроллер определен, просто опустите его в контроллер. Когда я говорю "Модель", это может быть отдельный проект, который кодирует вашу модель данных сущности, или может быть модель просмотра, или это может быть только папка "Модели" вашего проекта MVC.