Пожалуйста, дайте мне знать, если это хорошая архитектура для подражания?
Это хорошее начало - единственное, что я бы предложил вам добавить, это слой абстракции между вашей бизнес-логикой и доступом к данным (т. Е. Инверсия / внедрение зависимости) - см. Это: Введение в инверсию зависимости .
я знаю, что это не обязательно, но я думаю, что это делает проект более профессиональным: -)
* +1016 * Ха! Обычно вы обнаружите, что многие «вещи» не являются
необходимыми - вплоть до того момента, когда это происходит, когда обычно уже слишком поздно.
Просмотр двигателей: я сам еще новичок в ASP.NET MVC и поэтому не знаком с механизмами просмотра, о которых вы говорите; на вашем месте я бы придумал несколько тестовых сценариев, а затем попытался бы использовать их для каждого продукта, чтобы вы могли напрямую сравнить их. Часто вам нужно взять тест-драйв, чтобы он был более комфортным - хотя это может занять некоторое время, но обычно оно того стоит.
Изменить:
Если я предложу этот слой своему премьер-министру и укажу ему две вышеуказанные причины, то я не думаю, что он примет его
Во-первых, PM - это не технических отведений (обычно); Вы несете ответственность за дизайн решения, а не PM. Это не редкость, по моему опыту, большую часть времени премьер-министр даже не подозревает, что он посягает на ваш газон, что не так. Дело не в том, что я «политический захватчик земли», я просто склонен думать о «разделении интересов», и, я уверен, вы понимаете.
Как дизайнер / архитектор, вы должны интерпретировать требования и (принимая во внимание бизнес-приоритеты) найти решение, обеспечивающее наилучшую «платформу» в будущем.
(Относительно DI). Мой вопрос, действительно ли оно того стоит?
Если бы ты приставил пистолет к моей голове, я бы сказал да, однако реальный мир немного сложнее.
Если вы ответите «да» на любой из этих вопросов, лучше использовать DI:
- Система нетривиальна
- Ожидаемый срок службы системы больше, чем (не знаю, какая здесь правильная цифра, вероятно, ее нет, поэтому я собираюсь поставить ставку на землю) на 2 года.
- Система и / или ее требования являются текучими.
- Разделение работы (BL / DAL) на разные команды будет выгодно для проекта (возможно, вы являетесь частью распределенной команды).
- Система предназначена для рынка с разнообразным техническим ландшафтом (например, не каждый захочет использовать MS SQL).
- Вы хотите выполнить качественное тестирование (это упростит процесс).
- Система большая / сложная, поэтому возможно разделение функциональности и ее использование в других системах.
- Вы хотите предложить более одного способа хранения данных (скажем, хранилище на основе файлов бесплатно и хранилище на основе базы данных за плату).
- Бизнес-драйверы / среда нестабильны - что, если они придут к вам и скажут: «Это отлично, но теперь мы хотим предложить облачную версию, можете ли вы установить ее на Azure?»
Я также хотел бы отметить, что, хотя определенная вовлеченная кривая обучения, она не так уж велика, и как только вы наберете скорость, вы все равно будете по крайней мере столь же быстры, как и сейчас; или, в худшем случае, вам потребуется немного больше времени, но вы будете приносить гораздо больше пользы (при относительно меньших усилиях).
С точки зрения того, сколько усилий требуется ...
Одноразовые задачи (помимо ускорения работы команды):
- Написание загрузчика провайдера или выбор DI Framework. Как только вы это сделаете, он будет многократно использоваться во всех ваших проектах.
«Новые» общие задачи (при условии, что вы придерживаетесь подхода, принятого в статье):
- Определение интерфейса (на бумаге) - это то, что вы будете делать прямо сейчас, за исключением того, что вы можете этого не осознавать. По сути, это OO Design, но так как это будет формальный интерфейс между двумя или более пакетами, вам нужно подумать (и да, вы все равно можете его реорганизовать - но в идеале интерфейс должен быть «стабильным» и не сильно меняться; если он действительно изменится, лучше «добавить», чем «удалить или изменить» существующих членов).
- Написание кода интерфейса. Это очень быстро (минуты, а не часы), так как вы не пишете никакой реализации; и когда вы приступите к реализации, вы можете использовать инструменты, предоставляемые вашей IDE, для создания заглушек кода на основе интерфейса.
То, что вы делаете сейчас, что вы делаете по-другому:
- Создание переменной (в ваших классах BL) для хранения провайдера, возможно, через фабрику. Написание этого не должно занять много времени (опять же, минуты, а не часы), и это довольно простой код для копирования, вставки и рефакторинга, где это необходимо.
- Написание кода DAL: должно быть таким же, как и раньше.