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

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

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

Поэтому я склоняюсь к следующей схеме:

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

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

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

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

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

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

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

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

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

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

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

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

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

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