Ясно. При таком подходе вы будете снова и снова дублировать логику извлечения объектов откуда-то (например, из базы). Не считая уже того, что для сложных представлений эти конструкторы будут нечитабельными. И для генерации модели вида сложной страницы мы получим здоровенный кусок кода, где все будет в одной куче. Лучше на мой взгляд использовать возможности, вроде Include, для загрузки всего графа объектов доменной модели одним запросом, чтобы не обращаться к БД более 1го раза. Или же делать некий специальный объект-источник всех необходимых доменных объектов, откуда их могут брать все модели вида, подлежащие рендерингу при текущем запросе.
Хотелось бы лучше понять ваш подход, т. к. меня действительно беспокоит возможное количество обращений к базе в предложенном мной решении. Если взять для примера страницу, на которой отображается список объектов А, каждый из которых еще отображает объект Б. И если представить, что объекты А отображаются повсеместно на других страницах, т. е. не зависит именно от страницы списка. И объекты Б также используются отдельно. Каким образом строить иерархические структуры и избегать дублирования кода И множества запросов к БД, если все данные должны передаваться в конструктор? А если вложенность моделей видов еще глубже?
В таком случае, если для построения модели вида используется конструктор, сама модель вида должна обращаться к базе данных для инициализации вложенных моделей видов. Меня это очень смущает. Задача модели вида, на мой взгляд, лишь представлять данные, необходимые для представления, и не больше. А за создание и построение моделей видов должно отвечать нечто внешнее, типа билдера-фабрики. Да, это увеличивает количество классов, но это делает код абсолютно читаемым и в нем очень легко разобраться.
В этом примере — да. Но чаще бывает вывод чего-то вроде списка товаров, для которых все вложенные вещи обычно можно загрузить при помощи JOIN. Но. Даже в таком случае можно что-то придумать, чтобы выгрузить все мероприятия на месяц за 1 раз. Это уже скорее вопрос оптимизации, чем подхода в целом.
Да, согласен. Здесь следует быть внимательным. Хотя если используется нечто вроде EF с Include то все вложенные сущности могут быть загружены одним запросом.
Компоненты как раз и созданы для вывода комментариев или чего-то подобного (т. е. самодостаточных блоков), вы правы. Например, я вывожу блоки меню и форм в своем проекте с использованием компонент. Но модели вида это немного из другой оперы. Например, вы можете в компоненте вывести календарь, и опять упретесь в необходимость передачи данных в его вьюху. Не будете же вы вставлять в компонент еще 42 других компонента? Т. е. это дополняющие друг друга вещи, а не взаимоисключающие. Кстати, есть мнение, что компоненты (а в предыдущих версиях ASP.NET — конструкции вроде Html.Action(), т. е. рендеринг результата некого запроса внутри представления) как бы нарушают концепцию MVC. Нарушают даже не в плохом смысле, а просто как факт.
Т. к. модели вида не маппятся, а конструируется из разных кусков, лучше все-таки наверное Builder переименовать в Factory, и метод Build переименовать тоже. Тогда это будет вполне отражать суть. А мапперы применяются для обратного процесса — превращения модели вида (например, формы) в модель предметной области.
А как в таком случае избегать дублирования кода, когда во многих местах необходимо строить одни и те же модели видов? Все-равно ведь необходимо использовать какой-то класс, который будет содержать необходимый код? Расскажите, пожалуйста, подробнее.
Да, наименование так себе. Вот тут подробнее ответил.
Я согласен, что местами модели видов могут выглядеть избыточными, но какое есть решение? Использовать в некоторых местах модели видов (не помещать же все необходимые данные во ViewBag), а в других — «сырые» объекты предметной области? Это очень усложнит чтение кода, он перестанет быть однородным и это бОльшее зло, чем несколько доп. классов, на мой взгляд.
Согласен, что следует подходить к этому вопросу внимательно и не добавлять билдеры там, где они не нужны. Но не могу согласиться с тем, что следует удалить все билдеры, кроме календаря. Повторное использование это постоянное явление. Если снова посмотреть на магазин: товар отображается в списке товаров, в списке рекомендуемых и просмотренных товаров, в корзине, в предыдущих заказах и еще в куче мест. Можно использовать различные представления, но одну модель вида для них всех. Можно управлять глубиной построения модели вида, когда это необходимо. Но это в целом решает 2 важные задачи: избавление от дублирования кода и четкие и понятные рамки ответственности различных классов. В статье я привел очень упрощенный пример, возможно из-за этого сложилось такое мнение.
Согласен. Но тут дело не в паттерне, а в названии класса. Билдер в данном случае не означает, что используется шаблон проектирования Строитель. Почему-то так повелось, использовать для построения модели вида билдер, а для обратного процесса — маппер. Я иногда задумывался об этом. Возможно, действительно стоит пересмотреть подход к наименованию, чтобы не было путаницы.
Спасибо! Конечно, сложно не знать об одной из самых популярных CMS на ASP.NET :) Интересно было посмотреть, как у них реализована модульность. В свое время я здорово помучался на этой теме.
Если считаете свойство лишним — просто удалите его из соответствующего класса и оно исчезнет. Контентом управляете вы. Что касается META-keywords, то как-то читал об эксперименте. Ребята придумали несуществующие слова и на полностью новом сайте добавили их только исключительно в META-keywords. После индексации гугл показывал сайт по соответствующему запросу. Это было не так давно, ссылку уже не найду, наверное. Но, повторюсь, в данном случае полная свобода в плане свойств, решать вам.
Не совсем. Отдельные вьюхи создаются для отдельных классов объектов. Т. е. у всех новостей может быть одинаковая вьюха, но если необходимо, можно для какой-то особенной новости задать особенную вьюху.
Если я правильно вас понял, то да, согласен, нужно сделать возможным редактировать представлений прямо из админки в будущем (как это сделано в Ubraco, например). Сейчас это приходится делать через внешний редактор + необходим доступ к файловой системе сайта.
Ожидаемый и логичный вопрос, спасибо. Я фанат C# и ASP.NET, не буду скрывать. На этой платформе не так много хороших CMS. Мне нравится, например, Umbraco, но пока-что насколько я знаю она не портирована на ASP.NET Core. Также мне не слишком по душе ее архитектура и сложность (в технологическом плане), вызванная, наверное, частично, большим сроком в open source. Хочется иметь простую, быструю и расширяемую систему на новой платформе, чтобы писать на C# и при этом не быть привязанным к Windows-среде, т. к. многим клиентам не нравится это ограничение (и их можно понять). Можно было бы посмотреть в сторону Java, там тоже есть и хороший язык (который я знаю благодаря Android-разработке) и кроссплатформенность, но, как я уже сказал, весь стек от MS мне как-то ближе что-ли. Так что, отвечая на ваш вопрос, я бы субъективно назвал сильными сторонами хорошую платформу, язык, легкость, расширяемость, простоту использования.
Хорошая статья. Думаю, прочесть это будет очень полезно начинающим. От себя могу добавить, что нужно доверять своим внутренним ощущениям, внимательно прислушиваться к ним и избегать сотрудничества с теми, кто уже на первой встрече вызывает сомнения (даже если это смутные отголоски). Особенно внимательным следует быть, когда заказчик торопится, говорит, что все должно было быть сделанным уже месяц назад, или что предыдущая команда, которая работала над проектом, почти все сделала, но сотрудничество с ней пришлось прекратить в силу некоторых причин и теперь нужно срочно «довести проект до ума» и что «тут особо нечего делать» или необходимо «поправить баги и внести пару правок». Также следует быть осторожным начиная работать с чужим кодом (как упомянул автор статьи), т. к. заказчик далек от процесса разработки программного обеспечения и не оценит усилий, затраченных на переписывание чужого кода плохого качества или же мучений с этим кодом, а скорее обвинит вас в срыве сроков или в низком качестве результатов. Из опыта могу сказать, что я мог бы избежать тех нескольких неприятных опытов сотрудничества, которые у меня были, если бы следовал этому своему совету раньше.
Кстати, rem имеют лучшую поддержку в браузерах и мы уже повсеместно используем их в рабочих проектах, добавляя правила с px для совместимости.
Я согласен, что местами модели видов могут выглядеть избыточными, но какое есть решение? Использовать в некоторых местах модели видов (не помещать же все необходимые данные во ViewBag), а в других — «сырые» объекты предметной области? Это очень усложнит чтение кода, он перестанет быть однородным и это бОльшее зло, чем несколько доп. классов, на мой взгляд.
Если я правильно вас понял, то да, согласен, нужно сделать возможным редактировать представлений прямо из админки в будущем (как это сделано в Ubraco, например). Сейчас это приходится делать через внешний редактор + необходим доступ к файловой системе сайта.