Я унаследовал плохо спроектированное и организованное приложение ASP.NET MVC, которое представляет собой систему онлайн-бронирования для поставщиков медицинских услуг. Кажется, что он был разработан с использованием очень небольшого количества объектно-ориентированных принципов и небольшой абстракции или SoC. Итак, я переписываю большую часть внутреннего кода.
Я внедрил Entity Framework 6, чтобы заменить текущие прямые вызовы базы данных, которые заполняют таблицы данных, которые возвращаются вызовами статических методов. Я создал уровень бизнес-логики (BLL) и уровень доступа к данным (DAL) (в папках/пространствах имен в том же проекте, а не в виде библиотек классов). Я храню классы сущностей базы данных в папке Models.
Я переписываю свои контроллеры как «тонкие» контроллеры, которые берут данные приложения, преобразуют их при необходимости и создают объекты BLL, которые выполняют все необходимые действия. Затем контроллер манипулирует возвращенными данными в представления и т. д.
Где должны быть вспомогательные классы/методы, которые манипулируют данными объекта BLL для представлений?
Например:
У меня есть класс BookableTreatments
BLL, который содержит все процедуры, которые можно забронировать. Для представления требуется элемент HTML Select с параметром для каждого лечения, предлагаемого конкретным поставщиком. Поэтому я мог бы создать вспомогательный класс SelectListGenerator
, у которого есть метод, который принимает объект BookableTreatments
и ProviderID
и возвращает IList, который можно использовать для генерации выбора HTML.
Где должен находиться мой класс SelectListGenerator
? Это не контроллер, это не бизнес-логика, поскольку она зависит от приложения. Должен ли я создать новое пространство имен и папку с именем ALL (аббревиатура от Application Layer Logic, а не слово «все»), которое содержит только классы для такого рода целей? Я не ожидаю, что будет огромное количество таких классов.
(Обратите внимание, у меня есть класс BookableProviders
, который содержит информацию о поставщике, и я мог бы включить в этот класс список процедур, которые предлагает поставщик. Поэтому я понимаю, что может быть лучше сделать это, а не иметь список процедур, которые я нужно фильтровать для конкретного провайдера, но это не связанная проблема. И даже если это так, мне все равно нужно создать список выбора для представления. Итак, вопрос остается в своей общей форме)
Спасибо!
Этот вопрос освещает мою самую большую критику веб-фреймворков MVC, в которых есть папки с названиями "модели", "представления" и "контроллеры". Фреймворк Microsoft ASP.NET MVC - не единственный нарушитель. Возможно, изначально этим грешил фреймворк Ruby on Rails MVC для Ruby.
Папки с названиями models, views и controllers заставляют людей думать, что каждый файл и класс должен быть отнесен к категории model, view или controller. Не путайте паттерн проектирования Model-View-Controller с архитектурой приложения.
Шаблон MVC - это шаблон проектирования пользовательского интерфейса. Он не описывает каждый слой или область архитектуры вашего приложения. То, как вы организуете бизнес-логику, авторизацию, аутентификацию, доступ к данным и даже проверку пользовательского ввода, не охватывается шаблоном MVC. Помимо моделей, представлений и контроллеров, организация кода зависит от вас и вашей команды. Делайте то, что имеет смысл.