Структура проекта ASP.NET Model View Presenter
Я только начинаю новый проект ASP.NET и использую шаблон MVP. Я рассматривал MS MVC, но он еще не выпущен и может стать большой кривой обучения для некоторых людей в команде, поэтому я выбрал MVP сейчас и, возможно, будущие проекты MVC.
В любом случае, похоже, у меня будет один класс Controller / Presenter для каждой веб-формы, которая у меня есть в проекте. Это множество дополнительных классов, которые по сути удваивают количество файлов в веб-проекте. Это то, как другие люди структурируют MVP или каковы альтернативы?
Ответы 3
Я думаю, что многое от этого зависит, но в большинстве случаев это действительно так.
Я лично использую n-уровневую архитектуру с кодом данных, бизнеса, представления. (Кто знает, какому актуальному формату я следую). У меня действительно намного больше файлов, чем если бы я делал все в aspx, но с кодом намного легче управлять.
Кажется, это распространенное заблуждение -> «Больше файлов / классов == более сложные»
Причина, по которой мы решили следовать шаблону разделения пользовательского интерфейса, состоит в том, чтобы помочь разделить проблемы, упростить и удешевить изменение и обслуживание кода и (большой, важный и) мы можем модульное тестирование сложных частей и при этом сохранить тонкий слой пользовательского интерфейса.
Я собираюсь использовать бета-версию ASP MVC. Причина в том, что, хотя это еще только бета-версия (PDC очень скоро, это может повлиять на выпуск, и у нас было 5 предварительных версий), у него есть лучшая структура для поддержки этого стиля, чем я мог бы написать за разумное время. Рамка.
Вы, конечно, можете использовать другую структуру, например замковую монорельсовую дорогу.
Я лично хотел бы пойти с ASP.NET MVC. Я сам использовал его для www.jobtree.com.au. К сожалению, многим разработчикам не нравится идея потерять свои GridView и другие визуальные компоненты. :-П
На ваш вопрос - я видел много разных подходов к MVP и не видел ничего, что уменьшало бы количество файлов, и я не могу придумать способ уменьшить количество файлов.
По моему опыту, я повторно использовал интерфейсы представлений и даже код, в котором структура представления идентична, но представляет разные данные. И вы также можете подумать о повторном использовании контроллеров, где это возможно.
Я думаю, стоит отметить, что наличие большего количества файлов будет естественным следствием перехода к более гибкой и тестовой разработке, и разработчики будут находить это все более и более естественным по мере продвижения. (Так же, как некоторые из нас считают очень естественным иметь множество методов внутри одного файла ...)
Это очень похоже на то, что есть у меня. У меня есть модели, сервисы и веб-слои.