Ага, интересно, как вы решите проблему, когда у вас есть простой CRUD PersonsService. Но вот новая задача, при удалении Person нужно оповестить админа. Получается CRU методы получают в нагрузку INotificationService депенденси, хотя не используют ее. Или вы предлагаете создать IPersonsDeleteService? Может я что-то не знаю, но по-моему In-Memory CQRS решает эту проблему на ура.
Суть моих претензий заключается в том, что вы рассказали об очень узком паттерне, при этом подали это все под соусом DDD, наделав кучу антипаттернов в примере. Упрощение для примера — не оправдание говнокоду! Вы даже с IDisposable перемудрили в коде UoW.
Если вы не испытываете проблем с вызовом методов, как же вы решаете проблему с раздуванием количества зависимостей в сервисах?
Да, валидация — это часть домена, с одной стороны, а также Cross cutting concern с другой, поэтому нужно писать код, учитывая этот дуализм. Никто не мешает вам упаковать валидаторы в один проект с доменной логикой.
Абсолютно соглашусь с вашим комментарием. На мой взгляд статья очень поверхностная и ушла на полшага вперед от пресловутого примера Blogs/Posts, а может и даже вредная. Вся эта мишура рассыпается, как только нужно сделать безнес транзакцию между несколькими доменами. Например, навестить админа, что кто-то сменил фамилию. Или добавить троттлинг на чтение пользователей.
Добавлю от себя еще 5 копеек. Если проект не очень сложный, но есть желание поиграть в ДДД, то в первую очередь нужно создавать доменные DbContext. Далее следует сменить, так сказать, mindset и вместо вызовов методов нужно посылать сообщения между подсистемами. Для этого советую воспользоваться библиотекой MediatR для начинающих или GreenPipes, если охота больше хардкора. Для более сложных проектов нужно переходить к message broker'ам. Тут поможет MassTransit или NServiceBus.
Еще интересует, зачем вы смешали валидацию и VO? Посмотрите насколько убог код вашего контроллера. 3 одинаковых if. А что если я добавлю еще одно правило? Мне надо не забыть изменить еще код контроллера? Для этих целей советую изучить библиотеку FluentValidation.
Если хотите узнать, про настоящее DDD советую доклады Jimmy Bogard'a. А также must see вот это видео, где подробнее раскрыты тезисы из моего комментария.
На мой скромный взгляд, DDD это вообще не про EF и не про UoW в EF зло или нет (зло). Это все слишком низкоуровневые вещи. DDD — это про правильное разделение приложения на Bounded Context, а также разработка протоколов передачи сообщений между этими самыми Bounded Context.
Выглядит круто, но не спешите использовать это в продакшне до тех пор пока не будет нормального официального примера, как их использовать в более менее сложном сценарии (как минимум с формами) и нормальной документации. Потому что в CustomElements + Forms до сих пор есть баг #24181, который висит больше чем полгода. Честно говоря, я вообще не понимаю, как можно такое выпускать в продакшн.
Этот баг можно обойти только через 5ю точку. В общем я описал свои приключения с Custom Elements в этом комменте. Мое личное мнение, на данный момент, если у вас большой опыт работы с Angular и вы хотите сделать библиотеку корпоративных компонетов либо пойти по пути Micro-frontent, то лучше сделать ресерч и небольшой proof of concept и оставить их до лучших времен (выход Ivy + 6 мес).
Не уверен, что это возможно. Такая функциональность противоречит идеологии фреймворка. Закрепление изменений происходит во время вызова метода SaveChanges(). EF и EFC хранят граф объектов и следят за изменениями. По накопленным изменениям генерируются UPDATE, INSERT, DELETE. Каким образом DeleteAsync превратится в граф объектов? Вы, конечно, можете написать простую логику:
Загрузить все объекты x.Price > 2000
Удалить их. Но это будет ужасный оверхед.
Вообще, знающие люди говорят, что Bulk Operations и ORM это из разных областей.
Интересная фича, спасибо за наводку. Не думаю, что ее бы хватило для поддержки `CONTAINS` как минимум из-за того, что `DefaultQuerySqlGenerator` не достаточно универсален и проблема с `= 1` никуда бы не ушла (#9143). Но надо обязательно попробовать этот функционал.
Да, очень бесит это «улучшение». Если EF6 не может что-то трансировать, то кидает исключение, что мне и надо. Это значит я написал кривой запрос и его надо пофиксать или переделать логику и явно написать `foreach`. EFC молча проглатывает все и исполняет локально. Нет, спасибо, не надо мне такой услуги.
Пробовал завести Angular2 i18n, все сыпалось с ужасными ошибками. Видимо, он еще не очень дружит с Angular Universal. Пришлось использовать старый, добрый, знакомый с первого Angular'a ng-translate. Кстати, не знаю у кого как, но вечные замечания от мереджеров/UX типа: «тут надо запятую поставить», «тут с большой буквы», «не хватает перевода, пожалуйста добавь» у меня вызывают нервный тик.
Поэтому я заэкстендил [translate] директиву, чтобы она добавляла маленькую кнопку к тексу, чтобы можно было перевести все и записать изменения прямо на сервер. Единственный недостаток, что при редеплое все изменения могут быть потеряны, но я всем объяснил, чтоб сохраняли *.json c переводами и отсылали его по почте.
Кстати, кому-нибудь интересен данный подход?
PS: естественно этот код даже не подключается в продакшне.
Спросите у ребят из JetBrains, например, как R# весело жилось в одном процессе с 32 битной VS. Вообще, эта проблема стоит остро у любой команды, которая пишет плагин. 3Gb адресного пространства доступно всего. Как правило 2 отъедает хост. Итого, на плагин остаётся всего лишь 1-1.5 Gb. Нам тоже пришлось поплясать с бубном при написании плагина к 32 битному ArcMap'y. Какого х, имея железо с 32Гб оперативной памяти, я вообще должен париться об этом?
А что такого ужасного в этой картинке?
А то, что MS — это компания, на которую, по идее, должны все равняться в Windows мире, а она уже как 10 лет не может выродить IDE, адекватное современным реалиям.
Тоже поддержу вас. У меня такое чувство, что автор ни разу не пользовался ноутами с сенсорными экранами. Лично мое мнение, что это мертворожденная идея, хотя трансформеры мне нравятся.
У нас на работе у прогеров обычные 15" ноуты, а у менеджмента 13" с сенсорными экранами. Так вот, почти никто эти сенсорные экраны не пользует. А как автор себе это представляет? Руки на ноутбуке лежат в максимально удобном состоянии, затем внезапно надо одну из них оторвать, и на расстоянии вытянутой руки навесу тыкнуть в куда-то, затем вернуть на место. Тут накладные расходы на эти движения будут выше ценности самого действия. Экран ноутбука ведь находится гораздо дальше, чем у планшета, например.
Однажды наблюдал, как наша HR пыталась выделить текст сенсорным вводом, куда уж еще проще… Так ей пришлось отогнуть экран левой рукой градусов на 15, согнуться к экрану на 10-15 см и правой рукой выделить текст и вернуться в исходное положение. Очень юзер френдли, я считаю. И качественным софтом эти проблемы не исправить, так что Эппл в данной ситуации поддерживаю, а автора статьи нет.
Неправильная аналогия, считаю. У самсунга не было 20ти кратного запаса прочности. Нельзя так просто взять и отозвать over 9000 устройств, а откатить на предыдущую версию код можно.
Удалось ли вам дебажить JS код в VS? Visual Studio упорно хочет отлаживать bundle файл, и никак не хочет видеть source map'ы. Полгода назад пытался решить данную проблему, но с нулевым результатом. Приходится по старинке дебажиться в Chrome.
Представьте себе, в Ember тоже есть data-binding, и реализован он в тысячу раз лучше, чем в Angular, как с точки зрения производительности, так и удобства.
Мой друг использует Ember в своём проекте. Каждый день слышу как он тормрозит, как отожрал кучу памяти, как подкачал лишние данные. В нашем же проекте (привет Вилларибо и Виллабаджо) (инструмент просмотра и планирования электрических сетей) я прошел курс молодого бойца по JS после десктопа и вперед, колбасить код, я не думал об оптимизации от слова совсем, за исключением здравого смысла, и все прекрасно работает. Более того у нас главное требование — работа под мобильными устройствами с адаптивным дизайном. И оно работает на iPhone 4S без единого нарекания.
В реальных проектах вы сталкиваетесь с HTML-элементами, имеющих десятки атрибутов. И глядя на разметку, совершенно непонятно, какие из них являются кастомными директивами (eval'ятся, Карл!)
Эмм, ну не знаю, меня все устраивает. Делайте префиксы к вашим директивам, тогда будет понятно ху из ху, плюс никто не отменял принцип разделяй и властвуй.
какие несут значения в виде строк, какие eval'ятся (eval'ятся, Карл!).
Оператор :: убирает данную проблему.
Сделать на Angular тяжелый, сложный вэб-интерфейс просто невозможно.
На мой взгляд функционал нашего приложения будет даже больше, чем у, например, 2gis.ru. Не знаю, считаете ли вы его достаточно сложным, но у нас все работает хорошо, а в стеке продуктов компании есть еще множество решений на Angular и оно работает тоже отлично.
Что же вы так хейтите бедный angular, как будто он вас обидел чем-то.
перехожу работать в бостонскую команду, использующую Ember
— Бе бе бе, уйду от тебя к другому.
А если серьезно, то опыта работы с Ember у меня нет, поэтому сравнивать их с Angular не могу, но как человеку, пришедшему из мира WPF data-binding для меня является самой естественной сущностью и по одному взгляду на декларативную разметку сразу понятно, как изменится состояние приложения, если я кликну на эту кнопку.
На мой взгляд, кодинг с постоянной мыслью «за магию всегда надо платить» поможет избежать всех этих ошибок. Для меня эта статья оказалась подтверждением, что я делал все правильно, хотя нигде явно про это не читал. Правда, некоторые моменты для меня оказались новыми, за что автору спасибо. Как говорится, век живи — век учись.
Суть моих претензий заключается в том, что вы рассказали об очень узком паттерне, при этом подали это все под соусом DDD, наделав кучу антипаттернов в примере. Упрощение для примера — не оправдание говнокоду! Вы даже с IDisposable перемудрили в коде UoW.
Если вы не испытываете проблем с вызовом методов, как же вы решаете проблему с раздуванием количества зависимостей в сервисах?
Да, валидация — это часть домена, с одной стороны, а также Cross cutting concern с другой, поэтому нужно писать код, учитывая этот дуализм. Никто не мешает вам упаковать валидаторы в один проект с доменной логикой.
Добавлю от себя еще 5 копеек. Если проект не очень сложный, но есть желание поиграть в ДДД, то в первую очередь нужно создавать доменные DbContext. Далее следует сменить, так сказать, mindset и вместо вызовов методов нужно посылать сообщения между подсистемами. Для этого советую воспользоваться библиотекой MediatR для начинающих или GreenPipes, если охота больше хардкора. Для более сложных проектов нужно переходить к message broker'ам. Тут поможет MassTransit или NServiceBus.
Еще интересует, зачем вы смешали валидацию и VO? Посмотрите насколько убог код вашего контроллера. 3 одинаковых if. А что если я добавлю еще одно правило? Мне надо не забыть изменить еще код контроллера? Для этих целей советую изучить библиотеку FluentValidation.
Если хотите узнать, про настоящее DDD советую доклады Jimmy Bogard'a. А также must see вот это видео, где подробнее раскрыты тезисы из моего комментария.
На мой скромный взгляд, DDD это вообще не про EF и не про UoW в EF зло или нет (зло). Это все слишком низкоуровневые вещи. DDD — это про правильное разделение приложения на Bounded Context, а также разработка протоколов передачи сообщений между этими самыми Bounded Context.
Этот баг можно обойти только через 5ю точку. В общем я описал свои приключения с Custom Elements в этом комменте. Мое личное мнение, на данный момент, если у вас большой опыт работы с Angular и вы хотите сделать библиотеку корпоративных компонетов либо пойти по пути Micro-frontent, то лучше сделать ресерч и небольшой proof of concept и оставить их до лучших времен (выход Ivy + 6 мес).
Не уверен, что это возможно. Такая функциональность противоречит идеологии фреймворка. Закрепление изменений происходит во время вызова метода
SaveChanges(). EF и EFC хранят граф объектов и следят за изменениями. По накопленным изменениям генерируютсяUPDATE,INSERT,DELETE. Каким образом DeleteAsync превратится в граф объектов? Вы, конечно, можете написать простую логику:x.Price > 2000Вообще, знающие люди говорят, что Bulk Operations и ORM это из разных областей.
Не чини то, что не ломалось :)
Поэтому я заэкстендил [translate] директиву, чтобы она добавляла маленькую кнопку к тексу, чтобы можно было перевести все и записать изменения прямо на сервер. Единственный недостаток, что при редеплое все изменения могут быть потеряны, но я всем объяснил, чтоб сохраняли *.json c переводами и отсылали его по почте.
Кстати, кому-нибудь интересен данный подход?
PS: естественно этот код даже не подключается в продакшне.
А то, что MS — это компания, на которую, по идее, должны все равняться в Windows мире, а она уже как 10 лет не может выродить IDE, адекватное современным реалиям.
И Preview 17 тоже.
У нас на работе у прогеров обычные 15" ноуты, а у менеджмента 13" с сенсорными экранами. Так вот, почти никто эти сенсорные экраны не пользует. А как автор себе это представляет? Руки на ноутбуке лежат в максимально удобном состоянии, затем внезапно надо одну из них оторвать, и на расстоянии вытянутой руки навесу тыкнуть в куда-то, затем вернуть на место. Тут накладные расходы на эти движения будут выше ценности самого действия. Экран ноутбука ведь находится гораздо дальше, чем у планшета, например.
Однажды наблюдал, как наша HR пыталась выделить текст сенсорным вводом, куда уж еще проще… Так ей пришлось отогнуть экран левой рукой градусов на 15, согнуться к экрану на 10-15 см и правой рукой выделить текст и вернуться в исходное положение. Очень юзер френдли, я считаю. И качественным софтом эти проблемы не исправить, так что Эппл в данной ситуации поддерживаю, а автора статьи нет.
Мой друг использует Ember в своём проекте. Каждый день слышу как он тормрозит, как отожрал кучу памяти, как подкачал лишние данные. В нашем же проекте (привет Вилларибо и Виллабаджо) (инструмент просмотра и планирования электрических сетей) я прошел курс молодого бойца по JS после десктопа и вперед, колбасить код, я не думал об оптимизации от слова совсем, за исключением здравого смысла, и все прекрасно работает. Более того у нас главное требование — работа под мобильными устройствами с адаптивным дизайном. И оно работает на iPhone 4S без единого нарекания.
Эмм, ну не знаю, меня все устраивает. Делайте префиксы к вашим директивам, тогда будет понятно ху из ху, плюс никто не отменял принцип разделяй и властвуй.
Оператор :: убирает данную проблему.
На мой взгляд функционал нашего приложения будет даже больше, чем у, например, 2gis.ru. Не знаю, считаете ли вы его достаточно сложным, но у нас все работает хорошо, а в стеке продуктов компании есть еще множество решений на Angular и оно работает тоже отлично.
А если серьезно, то опыта работы с Ember у меня нет, поэтому сравнивать их с Angular не могу, но как человеку, пришедшему из мира WPF data-binding для меня является самой естественной сущностью и по одному взгляду на декларативную разметку сразу понятно, как изменится состояние приложения, если я кликну на эту кнопку.
На мой взгляд, кодинг с постоянной мыслью «за магию всегда надо платить» поможет избежать всех этих ошибок. Для меня эта статья оказалась подтверждением, что я делал все правильно, хотя нигде явно про это не читал. Правда, некоторые моменты для меня оказались новыми, за что автору спасибо. Как говорится, век живи — век учись.