MVC архитектура большой метод действия на контроллере

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

Код включает в себя заполняющие списки для dropdownlists, присвоенных свойствам ViewBag, но большая часть размера занята EF (linq для сущностей) и в обработке памяти этого. И, наконец, отправлен на модель просмотра через Auto Mapper.

Где находится лучшее место для перемещения этого кода? В другом классе в папке Controllers? Или в другом классе в другой папке, то есть в бизнес-слое?

источник

2014-01-23 Thomas Veil

Насколько я понял, вы не имеете уровень доступа к данным.Если бы у вас было, вы могли бы переместить весь свой код обработки данных на этот уровень, тем самым освободив ваш контроллер. –

У меня есть модели и модели для просмотра, и я всегда думал, что у меня есть уровень доступа к данным (DAL). Но если DAL предназначен для включения бизнес-логики, тогда вы правы, у меня нет DAL. Если да, можете ли вы/кто-нибудь указать мне на лучшую практику DAL? Благодарю. –

Если у вас есть DAL, я думаю, что это хорошая идея, чтобы переместить ваш код, который включает в себя заполняющие списки для dropdownlists, назначенных свойствам ViewBag, но большая часть размера занята EF (linq to entity) "там. –

Отделить проецировании на:

WebUI (View, Controller-A MVC проекта)
Business Layer (Держит Business Logic - класс Библиотека проекта)
Data Access Layer (Держит Entity Model (Может быть EDMX) - Проект библиотеки классов)

Контроллер метода вызова проекта WebUI бизнес-уровня. Если бизнес нуждается в данных из базы данных, тогда он будет вызывать уровень доступа к данным.

источник

2014-01-23 07:50:05

Как ни странно, я ответил на очень похожий вопрос. yesterday. Вкратце ограничьте свой контроллер только минимальной логикой, чтобы связать ваши модели с вашими взглядами. Бизнес-логика, доступ к данным и т. Д. Лучше размещаются в отдельном репозитории.

источник

2014-01-23 08:27:24 Simon

Bappi Datta является правильным. Позвольте мне объяснить это с моей точки зрения.

Моя лучшая практика с LIBS AutoMapper, ФВ:

Web - включает в себя логику рендеринга, некоторые проверки, начальная загрузка конфигурации. Вызывает методы и классы бизнес-уровня.
Web.Models - веб-модели с атрибутами валидации
BusinessLogic - бизнес-уровень. Включает сопоставления EF Объекты < --->Web.Models. Использует классы данных.
Данные - здесь я всегда ставил EF-модели и контекст. Также может быть размещена реализация шаблона репозитория.

источник

2014-01-23 08:28:10 Andrei

Необходимо иметь уровень хранилища (о котором вы уже упоминали, у вас уже есть), а затем вам необходимо иметь уровень обслуживания, который будет содержать всю необходимую бизнес-логику, возможно, используя шаблоны, такие как Factory Factory и Facades. Затем, чтобы вы имели гибкую и легко подключаемую архитектуру, вам необходимо использовать Dependency Injection between all layers.

Read about MVC architecture in my perspective

Там могут быть разными Если и но в теоретическом обсуждении самой общей архитектуры MVC. Но, как правило, ваши действия с контроллером должны быть тонкими, ваша бизнес-логика должна быть в другом слое, отличном от репозитория.

enter image description here

источник

2014-01-23 08:30:42 ramiramilu

Injection Dependency ... Мне нужно будет изучить это и реализовать, когда уровень сервиса завершен. Спасибо, я слышал об этом, но никогда не рассматривал его. И великолепные инстинкты сайтов! –

MVC архитектура большой метод действия на контроллере

ответ

Смежные вопросы