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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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