Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?
Проблема, повторюсь, в том, что это логика защиты данных, и решать ее надо на уровне данных (хотя сами вычисления прав доступа станут частью бизнес-логики).
CQRS создан для оптимизации производительности (ну и плюс некоторые задачи на него хорошо ложаться), он не декларирует никак доступ к данным (ну за исключением разделения read/write data model), и ждать от него изящества в работе с данными не стоит, разве что можно добавлять фильтрацию по правам при восстановлении агрегата из набора событий.
Изящного решения этой проблемы нет даже в DDD, есть только более-менее удачные для конкретного проекта.
Удачное решение, как по мне, — это дополнительная модель данных, автоматически включающая секьюрити.
Я делаю так: есть два вида секьюрити: безопасность данных и безопасность операций.
Секьюрити операций сейчас пропустим.
Безопасность данных — это ограничение доступа к "чужим" данным, как на чтение, так и на запись. Реализуется она в виде фильтров данных, либо на стороне базы (row-level security или самопальный велосипед), либо генерацией и применением SQL фильтра (where) ко всем (в том числе update) запросам из сервера приложения. Если используется LINQ, можно такой фильтр генерировать в терминах доменной модели.
Основная проблема — это создать архитектуру данных, которая позволит сохранить баланс между избыточностью (денормализацией данных) и производительностью таких секьюрити-фильтров.
Отвечая более конкретно на ваш вопрос — если запись и чтение происходят в два источника, то логику придется дублировать, другой вопрос, что можно дублирование минимизировать, используя похожую структуру данных в read model и master data, интерфейсы и полиморфизм и т.п. Ну и конечно, надо отделить вычисление прав пользователя от преобразования набора прав в конкретный фильтр для сущности.
Спасибо за подробное описание. За годы работы выработал в себе интуитивное правило, которое только сейчас осознал: все библиотеки отстой, и чем четче граница между ними и бизнес-кодом с данными, тем лучше.
Основная идея Реакта — это быстрое обновление представления по новым (независимым от существующих) данным. В идеале — берем данные, рендерим вью, меняем данные (как угодно), даем вью — получаем оптимальное (ну или хотя бы достаточно быстрое) обновление представления.
Для меня в этой концепции самое привлекательное — это максимальная изоляция состояния и представления друг от друга, и связь между ними по четким, минимальным и контролируемым каналам. Тот же редакс хорош не тем, что он понятный или простой, или удобно ложится на джаваскрипт — он запутанный, особенно с непривычки, требует усвоения новых паттернов, и сложен для выражения в недофункциональном джаваскрипте.
Но при этом всем он вообще не требует вью для своей работы. Он не требует библиотек, наследования, использования своих сервисов или своей реализаций коллекций. И это прекрасно, а вдвойне прекрасно, что их там некуда впихивать (иначе кто-нибудь их туда точно впихнул бы).
Что больше всего раздражало в Нокауте: конвертация и расширение загруженного JSON-a в Observable. Иначе не работали даже примитивные формы редактирования. Это проникновение библиотеки на уровень, где ее не должно быть, и без нее можно обойтись, когда постоянно нужно помнить, что у тебя — данные, а что — модели, и почему же, все-таки, они не могут быть одним и тем же.
Их очень легко оказывается недостаточно для какой-нибудь очередной задачи. С IQueryable таких проблем практически нет.
Таких проблем нет, есть другие — размазанный и дублированный код доступа к данным, который расположен в не предназначенном для него слое, который невозможно протестировать и инкапсулировать, например, в базе, при необходимости.
А в традиционном репозитории шаг влево-шаг вправо от голого CRUD — и привет.
Ну, в общем-то, в этом и смысл репозитория, так-то можно и SQL писать в коде, что, в определенном приближении, равноценно LINQ запросам в бизнес-логике.
Разделение на репозитории и сервисы нужно только в случае, если есть бизнес-логика.
Я идею теперь понял, забыл, что в названии статьи упоминался unit of work.
А где метод Save вызывается?
Вообще я считаю, что юнит ов ворк не самый удобный паттерн для приложений с бизнес логикой. Очень легко получить неконсистентность данных в памяти и в хранилище. Часто приходится вызывать сохранение несколько раз, транзакционность тоже через отдельные сохранения. После сбоя сохранения контекст может быть непригоден для использования.
Не претендую на абсолютную истину, но выглядит, как по мне, немного избыточно.
Почему для получения репозитория используется Service Locator pattern? Почему бы не внедрить репозитории в контроллер через DI?
Зачем интерфейсу репозитория знать о существовании IStorage, и почему бы не внедрить его через конструктор.
В чем вообще цель выделения IStorage, если все гвоздями прибито к Entity Framework?
Тут недавно был по большей части терминологический спор о том, в чем состоят обязанности репозитория. Не хочется его начинать снова, но я считаю, что в "стандартном" трехзвенном приложении нужны минимально следующие абстракции:
Сущности предметной области
Сервисы — классы, реализующие операции над сущностями; содержащие бизнес-логику
Репозитории — абстракции, позволяющие спрятать детали взаимодействия с хранилищем данных от сервисов.
Сорри, реализовывать компонент не стал, это пример результирующей разметки. Как видим, появилось много обвязки и дополнительных элементов. Плюс ХТМЛ для списка задач добавился в modal-body.
Это не то же самое. Т.к. в примере с реактом заголовок и тело панели — это, скорее всего, не просто содержимое панели, а может быть обернуто в теги, добавлены классы и т.д.
Это все справедливо, но не только для Реакта. В Ангуляре все то же самое, да, думаю, и в любом другом фреймворке тоже.
Главное — результат. Если мы генерируем html, результат — картинка в браузере. В конечном счете я хочу получить конкретный макет, конкретный вид сайта. И я хочу понимать, как эта картинка сформируется. Дробление шаблонов в React осложняет это понимание.
С точки зрения разработчика важная задача — это отделить компоненты разных уровней друг от друга, сформировать правильный уровень абстракции.
Реакт с этим справляется, наверное, лучше всех (из распространенных фреймворков),
Ну это уже проблемы менеджера, а не разработчиков, и уж никак не методологии.
Поддержу.
Особенный случай — это когда инициатива внедрения аджайл исходит от заказчика. Во всех виденных мною случаях это значит daily meeting и все.
Я только за аджайл, и считаю его передовой методологией сегодня.
Но прочитав комментарий PkXwmpgN я подумал, может я что-то пропустил, и бывают методологии без выматывающих митингов и нелепых действий?
Какая по-вашему идеальная методология?
По идее, вот это
функционал Unit Of Work.
Проблема, повторюсь, в том, что это логика защиты данных, и решать ее надо на уровне данных (хотя сами вычисления прав доступа станут частью бизнес-логики).
CQRS создан для оптимизации производительности (ну и плюс некоторые задачи на него хорошо ложаться), он не декларирует никак доступ к данным (ну за исключением разделения read/write data model), и ждать от него изящества в работе с данными не стоит, разве что можно добавлять фильтрацию по правам при восстановлении агрегата из набора событий.
Изящного решения этой проблемы нет даже в DDD, есть только более-менее удачные для конкретного проекта.
Удачное решение, как по мне, — это дополнительная модель данных, автоматически включающая секьюрити.
Я делаю так: есть два вида секьюрити: безопасность данных и безопасность операций.
Секьюрити операций сейчас пропустим.
Безопасность данных — это ограничение доступа к "чужим" данным, как на чтение, так и на запись. Реализуется она в виде фильтров данных, либо на стороне базы (row-level security или самопальный велосипед), либо генерацией и применением SQL фильтра (
where) ко всем (в том числеupdate) запросам из сервера приложения. Если используется LINQ, можно такой фильтр генерировать в терминах доменной модели.Основная проблема — это создать архитектуру данных, которая позволит сохранить баланс между избыточностью (денормализацией данных) и производительностью таких секьюрити-фильтров.
Отвечая более конкретно на ваш вопрос — если запись и чтение происходят в два источника, то логику придется дублировать, другой вопрос, что можно дублирование минимизировать, используя похожую структуру данных в read model и master data, интерфейсы и полиморфизм и т.п. Ну и конечно, надо отделить вычисление прав пользователя от преобразования набора прав в конкретный фильтр для сущности.
Спасибо за подробное описание. За годы работы выработал в себе интуитивное правило, которое только сейчас осознал: все библиотеки отстой, и чем четче граница между ними и бизнес-кодом с данными, тем лучше.
В общем-то, можно добавить, что CQS (разделение чтения и изменения данных) — это крайне полезный паттерн при любой архитектуре.
Черт, как же вы раскусили-то?
Основная идея Реакта — это быстрое обновление представления по новым (независимым от существующих) данным. В идеале — берем данные, рендерим вью, меняем данные (как угодно), даем вью — получаем оптимальное (ну или хотя бы достаточно быстрое) обновление представления.
Для меня в этой концепции самое привлекательное — это максимальная изоляция состояния и представления друг от друга, и связь между ними по четким, минимальным и контролируемым каналам. Тот же редакс хорош не тем, что он понятный или простой, или удобно ложится на джаваскрипт — он запутанный, особенно с непривычки, требует усвоения новых паттернов, и сложен для выражения в недофункциональном джаваскрипте.
Но при этом всем он вообще не требует вью для своей работы. Он не требует библиотек, наследования, использования своих сервисов или своей реализаций коллекций. И это прекрасно, а вдвойне прекрасно, что их там некуда впихивать (иначе кто-нибудь их туда точно впихнул бы).
Что больше всего раздражало в Нокауте: конвертация и расширение загруженного JSON-a в Observable. Иначе не работали даже примитивные формы редактирования. Это проникновение библиотеки на уровень, где ее не должно быть, и без нее можно обойтись, когда постоянно нужно помнить, что у тебя — данные, а что — модели, и почему же, все-таки, они не могут быть одним и тем же.
Таких проблем нет, есть другие — размазанный и дублированный код доступа к данным, который расположен в не предназначенном для него слое, который невозможно протестировать и инкапсулировать, например, в базе, при необходимости.
Ну, в общем-то, в этом и смысл репозитория, так-то можно и SQL писать в коде, что, в определенном приближении, равноценно LINQ запросам в бизнес-логике.
Разделение на репозитории и сервисы нужно только в случае, если есть бизнес-логика.
Я идею теперь понял, забыл, что в названии статьи упоминался unit of work.
А где метод Save вызывается?
Вообще я считаю, что юнит ов ворк не самый удобный паттерн для приложений с бизнес логикой. Очень легко получить неконсистентность данных в памяти и в хранилище. Часто приходится вызывать сохранение несколько раз, транзакционность тоже через отдельные сохранения. После сбоя сохранения контекст может быть непригоден для использования.
От NuGet как менеджера или от паблик реестра пакетов?
Не претендую на абсолютную истину, но выглядит, как по мне, немного избыточно.
IStorage, и почему бы не внедрить его через конструктор.В чем вообще цель выделения
IStorage, если все гвоздями прибито к Entity Framework?Тут недавно был по большей части терминологический спор о том, в чем состоят обязанности репозитория. Не хочется его начинать снова, но я считаю, что в "стандартном" трехзвенном приложении нужны минимально следующие абстракции:
Отфильтровать по типу элемента, по заданным свойствам, программно создать массив элементов и т.д.
Какого типа
content(иchilds)? Есть ли возможность их обработать?Попробую. Панель, в общем-то, довольной простой контрол, особенно придумывать нечего, но допустим, что мы хотим реализовать modal бутстрапа:
Сорри, реализовывать компонент не стал, это пример результирующей разметки. Как видим, появилось много обвязки и дополнительных элементов. Плюс ХТМЛ для списка задач добавился в
modal-body.Это не то же самое. Т.к. в примере с реактом заголовок и тело панели — это, скорее всего, не просто содержимое панели, а может быть обернуто в теги, добавлены классы и т.д.
Это все справедливо, но не только для Реакта. В Ангуляре все то же самое, да, думаю, и в любом другом фреймворке тоже.
С точки зрения разработчика важная задача — это отделить компоненты разных уровней друг от друга, сформировать правильный уровень абстракции.
Реакт с этим справляется, наверное, лучше всех (из распространенных фреймворков),