Здравствуйте, уважаемые читатели. Сегодняшняя статья будет о первом опыте обучения и обмена навыками с другими людьми. Мне предложили дать лекцию по паттернам
проектирования (GOF patterns) и по DDD паттернам, таким
как Repository и Unit of Work. По паттернам я решил зацепить только те из них, которые чаще всего используются в реальных приложениях и касаются разработки
под .Net Framework. В первой части ("Классические паттерны") я
рассмотрел список следующих паттернов:
- Singleton
- Factory Method
- Abstract Factory
- Prototype
- Observer
- Iterator
- Facade
- Command
- Adapter
- Proxy
- Composite
- Strategy
- Template Method
- Decorator
Список, вроде, небольшой – всего 14 паттернов.
Причем часть из них была упомянута вскользь, а для части были взяты
примеры, которые так или иначе использовались в реальных проектах.
Например, по Singleton паттерну мы обсудили проблемы
с тестированием, в чем его отличие от паттерна Monostate и другие простые вещи. Для паттерна Factory Method был рассмотрен
кусок кода, который я разработал для работы с протоколами Pop3/Imap и
Smtp. Исходники можно
взять по ссылке TestEmailWorker. Также сделал презентацию по паттернам
Observer, Mediator, Command, Decorator, Composite, Iterator в приложении WPF, которое отображало работу интернет-магазина.
Возможно, проблема
была в подаче материала, возможно – в неумении подавать такие сложные темы для
студентов. Как итог – заметного одобрения или понимания темы не было.
Единственный внятный вопрос, который прозвучал, – это была просьба объяснить
отличие паттерна Strategy от Factory Method. В остальных
случаях – либо полная незаинтересованность, либо полнейшая апатия. Вывод:
паттерны проектирования – это тема, которая не интересна студентам, да и, если быть
честным, то не любят ее даже многие Senior Developers. Мало того, многие из последних пишут крутой код
даже не зная, как называется тот или иной паттерн. Пишут код себе потихоньку, следуя SOLID принципам,
и все отлично работает. Я не говорю сейчас о каких-то клинических
случаях.
Для себя сделал однозначный вывод: лучше было,
вместо паттернов, рассказать о SOLID принципах на
реальном примере, а еще лучше – продумать идею и реализовать этот пример
на практике. Часа 2-3 для этого должно вполне хватить. По идее, это могло бы
более заинтересовать соответствующую аудиторию и вызвать много вопросов, почему
так, а не иначе. Заодно можно проверить себя в реальной ситуации, когда ответы
нужно давать по ходу дела. А так, выходит, все твои утверждения воспринимаются
как аксиома, вопросов нет, интереса тоже.
Вторая часть по
паттернам Repository и
Unit of Work была более
успешной. Наверное, потому что я начал с разбора реализации паттерна, который
приведен на сайте asp.net в статье Implementing the Repository and Unit of Work Patterns
in an ASP.NET MVC Application. Интересно, что у данного примера было почти 40000 тысяч скачиваний. Решил взять данный пример для разбора, потому что увидел несколько раз тупой
копипаст данного паттерна разработчиками в свои приложения. Иногда даже без
изменений. Никого не смущает, что использование слова Generic – это не понятно по каким правилам именование.
Второй нюанс – так называемое тестирование, о котором идет речь в статье. Как
тестировать реализацию класса UnitOfWork, если данный класс
наследован от интерфейса IDisposable? Покрыть unit-тестами очень проблематично. Дальше я не понимаю ребят, которые используют создание репозитория по первому обращению.
public GenericRepository<Course>
CourseRepository
{
get
{
if (this.courseRepository
== null)
{
this.courseRepository
= new GenericRepository<Course>(context);
}
return
courseRepository;
}
}
Всегда хотел спросить у таких людей, что они пробуют
сэкономить? Не создавать отдельные классы, а точнее вызвать создание
конструктора и передать ему ссылку на данный класс? А в курсе ли они, что
операция по созданию DbContext намного затратнее, чем все их вместе созданные
классы. Это, между прочим, легко замерить. А во-вторых, выигрыш в несколько
миллисекунд с ухудшением читабельности кода кажется не суперперспективным.
Учитывая, когда в примере 3-4 репозитория. Первое, что хочется сказать
приверженцам такого метода: “Не там оптимизируете, товарищи”.
Я немного
отклонился от своей темы о менторстве. В общем, после того как я показал, что и
крутым разработчикам свойственно ошибаться, у многих в глазах проявился интерес
и наконец-то стали поступать вопросы. Я успел показать парочку разных
реализаций данного паттерна. Продемонстрировал, как реализовать DI через конструктор (Constructor Injection) на примере IoC контейнера Autofac. Рассказал также, что в зависимости от подхода
разработки – классические MVC контроллеры или ApiController (Web API подход) – внедрение зависимостей может отличаться. Рассказал о некоторых
экзотических реализациях, например, через фильтры в ASP.NET MVC.
Как показала
практика, тема построения приложений на базе паттернов Repository и Unit of Work, как правильно
разбить это на слои, когда нужно добавлять слой слой Services вызывает оживленный интерес. Было приятно, что ребята наконец-то узнали для
себя, в чем отличие n-tier от n-layer архитектуры.
Если бы был второй
шанс, я бы для людей, которые пытаются понять, как правильно использовать тот или
иной подход, показывал это все на практике – от начала и до конца. Желательно, правда, чтобы для этого была настроена своя машина, так как, например у меня
случилась проблема, что база данных не смогла создаться через EntityFramework.
Итоги
Для себя сделал вывод: если хочешь рассказать о какой-то
классной вещи, лучше показать это наглядно. Во-первых, это сэкономит кучу
вашего времени на подготовку презентации; от вас только понадобится отличное
знание предметной области и умение ориентироваться в среде разработки и теми
областями, которые вы затрагиваете. Устное изложение материала все равно не
работает, если ваша аудитория – не профессиональные разработчики. А так ваша
задача сведется только к тому, что вы покажете все на примере. В общем, выводы
сделаны, опыт получен и решил поделиться им с вами, чтобы услышать советы
профессионалов, как они решают проблему, чтобы максимально заинтересовать
аудиторию. Спасибо за то, что дочитали это до конца.
Материалы к статье
доступны по ссылке - demo materials.
No comments:
Post a Comment