ASP.NET MVC: Шаблон ASP.NET MVC c DI-контейнером и прочими полезными добавками
Сайтостроение | создано: 07.01.2018 | опубликовано: 07.01.2018 | обновлено: 13.01.2024 | просмотров: 7148
Вы когда-нибудь задумывались о шаблоне для Visual Studio для ASP.NET MVC 5 c предустановленным DI-контейнером и система проекции одной сущности на другую (mapping)?
Чистый шаблон
Как часто вы начинаете делать новый проект на ASP.NET MVC 5 и как часто вы деалете один и тот же набор действий по установки "обязательных" компонентов? А если вы также как и я предпочитаете архитектурные решения сначала пробовать на тестовых проектах вместо того, чтобы переделывать весь "боевой" проект для проверки работоспособности нового (усовершенствованного) функционала, то вам просто неоходим новый проект не из "чистого" шаблона, который генерирует Visual Studio, а еще кучу "обязательных" компонентов. При этом существует вероятность, что вы не используете какие-то компоненты, которые встроены в шаблон по умолчанию. Например, я всегда удаляю BundleConfig и всё что с ним связано, потому что предпочитаю использовать gulp для минимизации и минификации JavaScript-скриптов.
"Обязательные" компоненты
На мой взгляд, некоторые компоненты не просто было бы не плохо иметь в приложении, а они просто обязательно должны присутствовать как часть системы и инфраструктуры. Конечно же вы можете возразить, что можно и без перечисленных ниже компонентов создать прекрасное приложение, которое будет работать годами. Не буду спорить по этому поводу, потому что эта полемика откинет нас назад к одной статье, в которой речь идет о "правильном" и "хороших" подходах при разработки программного обеспечения. Приведу лишь цитату автора:
Существуют два способа программировать, причем независимо от платформы: Первый - "правильный", второй - "хороший". Первый способ подразумевает использование различных инфраструктурных паттернов, шаблонов проектирования, SOLID и DRY подходы, абстракции, ООП и другие законы и правила разработки кода. Второй способ обычно называют нецензурным словом, или просто "лапшекод". И то, что этот подход работает уже хорошо!
Одно скажу, что с автором я полностью согласен. И как продолжение темы предыдущей статьи эта статья о шаблонах проектов, которые упрощают развертываение нового проекта, готового к вливаниями и прочим фишкам. Итак, список компонентов, которые по моему личному мнению должны присутствовать в современном приложении:
- Dependency Injection Container
- Projection (Mapping)
- Logging
- Адаптивная разметка
- Email уведомления
- Постраничный просмотр любого типа сущностей
- Проверка пользователя "на человечность" (Recaptcha)
- Минификатор и минимизатор (Gulp)
Вот такой, так называемый, checklist у меня перед глазами каждый раз, когда я создаю новый проект для теста или еще для чего. Для чего это надо? Хотите пример? Их есть у меня!
Пример использования
Допустим, у меня есть рабочий, или если хотите "боевой" проект, который уже построен по "правильному" принципу, то есть в нем уже всё кишит шаблонами проектирования, инверсиями зависимостей и прочей важной всячиной. Теперь представьте, что надо опробовать систему генерации шаблонов для рассылки сообщений, которая использует локализованные данные и построена на системе микросервисов. Представили? Хорошо. Далее представьте сколько надо "переделать" в проекте, чтобы интергрировать данный бизнес-процесс и отладить его работу. А вдруг опыт будет неудачным и придется "откатывать" изменения!
Лирическое отступление. Те, кто знаком с системой контроля версий (с любой из существующих) могуг рассмеятся мне в лицо, прочитав последний параграф. Да, вы правы, создать новый бранч, протестировать новый функционал и влить изменения, добавив новое - очень просто. А что если речь пойдет о проектировании архитектуры нового (еще не существующего) приложения? Тут два варианта, или "в омут с головой" или каждый раз создавать инфрастуктуру определенного формата для отладки работы тех или иных частей системы. А создать проект нажатием "одной кнопки" из шаблона - еще проще!
Тогда возникает мысль, сначала попробовать, что предположения сработают и протестировать все механизмы. Но тогда надо воссоздать архитектуру "боевого" проекта в новом проекте. Копирование "боевого" проекта - неправильное решение, потому что в "боевом" проекте слишком много чего от чего зависит. Правильный варинат тестировать нововведение как обособленную инфраструктурную единицу - микросервис!
Nuget-пакеты для каждого проекта
Я буду описывать компоненты, которые использую сам в каждом своем проекте. Первый в списке DI-контейнер. В моем случае это Autofac. Далее mapping, для него я использую (с недавнего времени) ExpressMapper. Надо сказать, что до недавнего времени я использовал Automapper. Но после того, как я познакомился с графиками производительности фреймворков по проецированию сущности на сущность, мои взгляды в корне поменялись. Дорогу быстрым!
Теперь поговорим, про логирование (logging). Любое приложение делает какие-либо действия (ведь, оно для этого и создается). И всегда хочется знать что, как и в какой последовательности, а еще с каким результатом было выполнено. Речь идет от "скрытых" от пользовательского интерефейса механизмах. Для этого обычно программисты записывают всё журнал событий. Такой даже у Windows есть. Для этих целей я использую log4net.
Адаптивная разметка - это когда ваше приложение "умеет подстраиваться" под любые разрешения экрана, на котором он отображается. Для этого существует (в том числе и для ASP.NET MVC) очень много различных UI-фреймворков, перечислять которые не имеет смысла. Я чаще всего использую bootstrap.
Рассылка уведомлений - это немаловажная часть "большого" приложения. Люди, которые каким-то образом связаны с ним должны быть в курсе того, что в приложении происходит. Системные администраторы должны знать что "зарегистрировался новый пользователь", или что "в блоге добавлен новый комментарий", или что "оплата по заказу отклонена" и т. д. Пользователи должны знать что, "получили бонус" или что его "заказ выполнен" и т.п. В общем, рассылка уведовлений неотъемлемая часть "правильного" приложения. Для этих целей я использую MailKit.
Просмотр большого списка товаров, например, из 100 000 единиц на одной странице, то есть когда загружаются сразу все, может приводить к некоторым "неудобствам". А если товаров немного больше, например, 1 000 000 единиц, то тут вообще возникает вопрос "загрузятся или сервер рухнет вместе с товарами в бездну reboot'ов". При цивилизованных подходах принято использовать разбиение товаров на порции, то есть на страницы. Для этого архитектурного изыска я использую PagedListLite.MVC.
Предпоследний в списке компонент, который используется для проверки пользователя на человечность - это RecaptchaNet. Никто не хочет, чтобы по его форме ввода "разгаливали" роботы, и тем более чтобы "плохие роботы".
Ну, и наконец, последний пункт - Gulp. Современное приложение невозможно без использования JavaScript-кода, а вот для их минификации, то есть "склеивания" в один файл, и минимизации я использую Gulp (реже grunt) - который по натуре таск-менеджер для автоматического выполнения часто используемых задач (например, минификации, тестирования, объединения файлов), написанный на языке программирования JavaScript.
Заключение
Некоторые читатели наверняка уже имеют в голове вопрос типа "к чему весь этот цирк?". А суть вот в чём. Я создал шаблон для "старта", то есть проект, вернее набор проектов, в которых уже используются описанные выше компоненты. Таким образом, вы можете просто клонировать его себе, обновить nuget-пакеты, переименовать solution и projects на названия, которые вам нужны. А после этого смело начинать писать бизнес-логику. При этом у вас уже будет Dependency Injection (autofac), projection или mapping (ExpressMapper), logging (log4net), разбиение на страницы (PagedListLite), result wrapper (OperationResult), EmailService (wrapper на MailKit), ORM (EntityFramework 6.x.x) и построенная нем система Repositories, настроены будут вынесены в JSON-файл (Calabonga.Configuration) и всё это будет уже настроено на адаптивную разметку (bootstrap UI, кстати, она изначально встроена в шаблон для ASP.NET MVC).
Шаблон выложен в GitHub.
Новые пакеты или другие варианты уже подключенных приветствуются!
P.S.: Microsoft.ApplicationInsight тоже удалена.