Мне кажется, это больше на паттерн Command похоже — задается некий контекст исполнения и собственно команда execute().
Если пофантазировать на тему развития модели классов для приведенного примера, то, операции не осуществляются же сами по себе. Их выполняют вполне конкретные агенты. ИМХО, можно было бы ввести сущности HRDepartment (кадровый отдел) и AccountingDepartment (бухгалтерия) — и вот у них могли бы быть методы fireEmployee() и payRedundancy().
Во-первых, для экранирования использования LINQ конструкций, специфичных для провайдеров.
Во-вторых, для улучшения структуры и читаемости кода. Мне кажется, что любой запрос (неважно, SQL, HQL, LINQ) сложнее select с 1-2 условиями должен быть перенесен в метод репозитория с четким и ясным названием. Не 10 строк WHERE… AND… NOT EXISTS… BETWEEN и т.п., а что-то типа findAllUncompleteOrders. (Отец Эванс шлет нам горячий DDD привет! :))
Linq настолько мощен, что его нельзя абстрагировать в своем DAL без потери функциональности.
Вопрос может быть наивный (с .NET знаком весьма поверхностно, живу в Java мире):
А разве нельзя накрыть эту мощную функциональность какими-нибудь репозиториями и, тем самым, последовать дао верного пути DAL? :)
смена MS SQL на Mongo увеличила объем кода приложения почти в 2 раза
Это как раз переход от одного класса данных к другому. Естественно, без переписывания никак.
На практике в любом серьезном проекте программа все равно неявно затачивается под конкретную СУБД и смена СУБД это далеко не только смена строки подключения
Здесь вопрос в том, что еще помимо строки подключения нужно исправить. При отсутствии DAL — это разбросанные по всему коду специфические SQL конструкции, при наличии DAL — все эти конструкции могут быть заключены в ограниченном наборе классов с выставленным API. Цена перехода для второго случая, как я думаю, существенно ниже.
А в случае «кровавого ынтерпрайза», где много данных и в каждый запрос добавляется нетривиальный предикат проверки прав
Ну, не во всех энтерпрайзах такое есть. А если и понадобится такой функционал, то, на мой взгляд, он должен быть инкапсулирован в отдельный компонент, который при переходе и дорабатывается.
Мне кажется, все эти вопросы задаются потому, что DAL воспринимается только как некий технический артефакт, через который идет работа с данными. Между тем, это в первую очередь принцип организации работы с данными, который должен соблюдаться не только на уровне архитектуры приложения, но и на организационном уровне.
Ну, начнем с того, что DAL и подходит не всем :) Его сфера применения — это большое предприятие («кровавый enterprise» :))
Использование «общего диалекта» приводит к тому, что на каждой СУБД работает неэффективный код. Не все это могут себе позволить.
На мой взгляд, сформулировано чересчур категорично :) Точнее было бы, как мне кажется, сказать «иногда может привести к тому, что на каких-то СУБД будет работать неэффективный код».
Конечно, такие ситуации будут встречаться, от качелей «универсальность VS эффективность» никуда не деться. Я думаю, что в таких случаях надо будет предусмотреть при организации DAL какие-то закладки, позволяющие выполнить нативный запрос. Но появление таких закладок должно быть исключением из правил и должно строго контролироваться на организационном уровне.
Но для аналогичной базы даже городить прям уж такой DAL не нужно, обычно этим занимаются драйвера БД и скрывают конкретную базу, детали зависят от языка и технологий,
В том-то и дело, что у разработчиков все равно остаются средства для использования vendor-specific особенностей конкретной СУБД. Никто не мешает, например, при работе через JDBC использовать специфичные конструкции Oracle или MS SQL. Драйвер это пропустит. А вот при работе через DAL такого сделать не получится.
а вот если вы захотите заменить внезапно SQL на NoSQL, Вы реально перепишете всю логику приложения, ибо то, что делалось простым SQL-запросом, теперь ни за что так запросто не будет. И никакой DAL тут не спасет.
Совершенно верно, и в статье об этом говорится: если мы выходим за рамки класса данных (например, переходим от реляционных данных к key-value), то приложение потребует перепроектирования.
Т.е. либо, имея SQL, Вы пишете логику, как будто его и нет и имеете совместимость все-со-всем, но при этом не имеете никаких плюсов SQL, либо Вы используете плюсы SQL, но не имеете возможность с него уйти, не переписывая почти всю логику.
Не совсем так: мы используем SQL, от него никто не отказывается, но некий общий диалект (м.б. стандарт SQL-92, SQL-99...), который гарантированно поддерживается всеми реляционными СУБД. И этот диалект и считается интерфейсом DAL для доступа к реляционным данным.
данные и их организация настолько сильно влияют на приложение, что их вот так запросто выделить в отдельный слой ну никак не получится.
В статье не предлагается заносить в DAL организацию данных приложения. Структура данных, конечно же, остается частью приложения. DAL предоставляет механизм для доступа к этим данным и, возможно, включает в себя какую-то специфику работы с данными, присутствующими в организации и распространяющуюся на все приложения, работающие в этой организации (например, глобальную политику доступа к данным).
Да, у меня такой же эффект, когда GTD перечитываю :) Очень мотивирует.
Файлик можно забрать отсюда: www.dropbox.com/s/ev51u32zdcw2n5c/DayPlan.xlsx?dl=0
Помечать задачи в столбце слева от наименования надо так: 3 — выполнено, 2 — ожидаю, 1 — отказаться. Для помидоров и процедур надо вводить 1.
Есть, и в посте они описаны :) Все тот же DoIt.IM, MLO а еще есть RememberTheMilk, Toodledo, Todoist. Для MacOS/iOS шикарное приложение Things и супернавороченный OmniFocus.
Если пофантазировать на тему развития модели классов для приведенного примера, то, операции не осуществляются же сами по себе. Их выполняют вполне конкретные агенты. ИМХО, можно было бы ввести сущности HRDepartment (кадровый отдел) и AccountingDepartment (бухгалтерия) — и вот у них могли бы быть методы fireEmployee() и payRedundancy().
Перезалил, попробуйте.
Во-первых, для экранирования использования LINQ конструкций, специфичных для провайдеров.
Во-вторых, для улучшения структуры и читаемости кода. Мне кажется, что любой запрос (неважно, SQL, HQL, LINQ) сложнее select с 1-2 условиями должен быть перенесен в метод репозитория с четким и ясным названием. Не 10 строк WHERE… AND… NOT EXISTS… BETWEEN и т.п., а что-то типа findAllUncompleteOrders. (Отец Эванс шлет нам горячий DDD привет! :))
Вопрос может быть наивный (с .NET знаком весьма поверхностно, живу в Java мире):
А разве нельзя накрыть эту мощную функциональность какими-нибудь репозиториями и, тем самым, последовать дао верного пути DAL? :)
Это как раз переход от одного класса данных к другому. Естественно, без переписывания никак.
Здесь вопрос в том, что еще помимо строки подключения нужно исправить. При отсутствии DAL — это разбросанные по всему коду специфические SQL конструкции, при наличии DAL — все эти конструкции могут быть заключены в ограниченном наборе классов с выставленным API. Цена перехода для второго случая, как я думаю, существенно ниже.
Ну, не во всех энтерпрайзах такое есть. А если и понадобится такой функционал, то, на мой взгляд, он должен быть инкапсулирован в отдельный компонент, который при переходе и дорабатывается.
Мне кажется, все эти вопросы задаются потому, что DAL воспринимается только как некий технический артефакт, через который идет работа с данными. Между тем, это в первую очередь принцип организации работы с данными, который должен соблюдаться не только на уровне архитектуры приложения, но и на организационном уровне.
Я работал в крупном российском банке, который сменил СУБД. На большом кол-ве существующих систем.
Если не сложно — можно подробнее про «плавали, ели»??
На мой взгляд, сформулировано чересчур категорично :) Точнее было бы, как мне кажется, сказать «иногда может привести к тому, что на каких-то СУБД будет работать неэффективный код».
Конечно, такие ситуации будут встречаться, от качелей «универсальность VS эффективность» никуда не деться. Я думаю, что в таких случаях надо будет предусмотреть при организации DAL какие-то закладки, позволяющие выполнить нативный запрос. Но появление таких закладок должно быть исключением из правил и должно строго контролироваться на организационном уровне.
В том-то и дело, что у разработчиков все равно остаются средства для использования vendor-specific особенностей конкретной СУБД. Никто не мешает, например, при работе через JDBC использовать специфичные конструкции Oracle или MS SQL. Драйвер это пропустит. А вот при работе через DAL такого сделать не получится.
Совершенно верно, и в статье об этом говорится: если мы выходим за рамки класса данных (например, переходим от реляционных данных к key-value), то приложение потребует перепроектирования.
Не совсем так: мы используем SQL, от него никто не отказывается, но некий общий диалект (м.б. стандарт SQL-92, SQL-99...), который гарантированно поддерживается всеми реляционными СУБД. И этот диалект и считается интерфейсом DAL для доступа к реляционным данным.
В статье не предлагается заносить в DAL организацию данных приложения. Структура данных, конечно же, остается частью приложения. DAL предоставляет механизм для доступа к этим данным и, возможно, включает в себя какую-то специфику работы с данными, присутствующими в организации и распространяющуюся на все приложения, работающие в этой организации (например, глобальную политику доступа к данным).
Файлик можно забрать отсюда: www.dropbox.com/s/ev51u32zdcw2n5c/DayPlan.xlsx?dl=0
Помечать задачи в столбце слева от наименования надо так: 3 — выполнено, 2 — ожидаю, 1 — отказаться. Для помидоров и процедур надо вводить 1.