Куда поместить функции, которые помогают мне выполнить задачи контроллера?
Существует ошибка/запрос новых функций для этого в системе управления ошибки Adobe. Голосование за него, если это важно для Вас.
5 ответов
Как я выразился в комментарии выше, меня слишком сильно интересует этот вопрос.
Во-первых, кажется неправильным создавать дополнительные каталоги (для других классов и утилит) напрямую в вашем проекте ASP.NET MVC. Кроме того, я не считаю, что это должно быть в модели. Для меня модель - это более или менее классы данных, которые каким-то образом представляют базу данных (или данные, которые мы пытаемся смоделировать). Вдобавок к этому, часто бизнес-функции (или «настоящие» фрагменты кода в вашем приложении) имеют дело с несколькими классами моделей одновременно, поэтому для них может не быть естественного места в каком-либо классе модели.
Я думаю, что склоняюсь к следующей схеме:
- Сделайте действиями контроллера очень маленькими ; всего несколько строк кода каждая.
- Сохраняйте модель простой и в основном лишенной функций, и поместите его в отдельный проект .
- Поместите весь ваш код , который выполняет всю «реальную» работу («бизнес-уровень») , в отдельный проект .
Таким образом, вы получите полную свободу выбора ваших собственных пространств имен, вы сможете создавать любое количество служебных классов, функций и вообще сможете структурировать свой код по своему усмотрению без ограничений со стороны ASP. NET MVC.
Это всего лишь идея. В настоящий момент я работаю над своим первым большим приложением ASP.NET MVC. Так что я собираюсь узнать, работает ли это на практике и как.
Таким образом, вы получите полную свободу выбора ваших собственных пространств имен, вы сможете создавать любое количество служебных классов, функций и вообще сможете структурировать свой код по своему усмотрению без ограничений со стороны ASP.NET MVC.
Это всего лишь идея. В настоящий момент я работаю над своим первым большим приложением ASP.NET MVC. Так что я собираюсь узнать, работает ли это на практике и как.
Таким образом, вы получите полную свободу выбора ваших собственных пространств имен, вы сможете создавать любое количество служебных классов, функций и вообще сможете структурировать свой код по своему усмотрению без ограничений со стороны ASP.NET MVC.
Это всего лишь идея. В настоящий момент я работаю над своим первым большим приложением ASP.NET MVC. Так что я собираюсь узнать, работает ли это на практике и как.
I have Model classes that have Crud and Poco like you have.
Apart from that I have Viewmodels that are used for the typed Views.
My Viewmodels are pretty big and used in a couple of views (around 10-15 viewmodels for the whole appplication). In my application these ViewModels ended up as being the perfect place for the code that seamed to big and repetetive for the controller actions.
For example I have some logic that is pretty near to UI when I add a Product to the Cart. I now have a method in the ViewModel: AddToCart(IProductService productService, ICartService cartService).
Вы можете подумать о создании некоторых служб, которые вы внедряете в свои контроллеры.
Это слишком широкий вопрос.
Этот вид бизнес-логики должен быть где-то в вашей модели.
Однако я считаю, что когда есть что-то, что действительно никуда не «подходит» - и у вас может возникнуть соблазн создать класс Utilities - это обычно хорошее место для использования методов расширения.
Возможно, вы можете добавить расширение методы в наборе данных, которые помогут вам с разбивкой на страницы?
Мне действительно нужна лучшая практика, подумайте о том, чтобы взглянуть на Domain Driven Design . Это не подходит для всех проектов и требует хороших навыков ООП, но я думаю, что это, без сомнения, «лучшая практика» ... пока вы можете себе это позволить; -)
Обратите внимание, что вы уже нарушаете DDD с тех пор, как вы используете шаблон Active Record (помещаете логику сохранения в сущности). Итак, я не говорю, что вы должны следовать DDD. Но грок все равно будет полезен.