Гибкость — в нашей системе используется 2 различных хранилища (это боевое) (при установке пользователь сам выбирает как ему удобно их хранить) и 1 хранилище для демонстрации ( быстрое, использует оперативку ), без хорошей прослойки отделяющей предметную область от хранилища это будет сделать туго.
Мощь в том что при работе с объектами предметной области клиента репозитория вообще не интересует ( он этого даже не знает) где, как и в каком виде хранятся данные, он просто формирует запрос в терминах предметной области.
ждый для себя сам решает — нужна ли ему абстракция повверх технологии хранения данных или нет.
. Вообще любое приложение может быть написано без какого либо проектирования и оно будет работать, до тех пор пока не изменяться требования к системе или не придётся менять технологии, а уже от этого любой более менее рыночный продукт не то что не застрахован, а наоборот этот этап его настигнет, и дальнейшее существование будет завесить от того на сколько он адаптируемый под новые задачи. Разделение слоев и выделение доменного слоя это очень мощная и гибкая система, хотя и очень при очень затратная по ресурсам.
Страшное заблуждение. Логика должна быть обратная. Насколько полезна сущность сообщения без подписей, если есть операции с сообщениями без подписей, то подписи и сообщения — разные сущности, а если нет, то одна.
Сообщение может существовать без подписи ( не подписанное ), а подпись без сообщения? Существование подписи без сообщения это плохо. Исходя из операций которые можно совершать над подписью -> проверить ее подлинность, без содержимого исходного сообщения это не возможно. Сообщение агрегирует в себе подпись и ни как иначе. Что касается
Repository и UoW я о них не писал
Я описал чем Объекты предметной области могут отличаться от объектов хранилища, а так же отсеиваются заведомо бесполезные операции
Есть система сообщений, каждое сообщение подтверждается подписью (ЭЦП), причем подписей может быть несколько, подпись характеризуется содержимым, признаком корректности и сертификатом. Сама по себе сущность подписи бесполезна, она агрегируется в сообщении и отдельно ее запрашивать у хранилища с точки зрения предметной области бессмысленно (а значит хорошо бы заблокировать эту возможность) — для подписей не делаем Repository (вообще Repository принято делать только для корней агрегации, в данном случае для сообщения). Удалить подпись у созданного сообщения запрещено ( сообщение создается и подписывается и назад уже дороги нет, так же как бы если подпись была поставлена ручкой ), поэтому во вне предоставляется интерфейс сообщения, который предоставляет не изменяемое перечисление подписей и метод по добавлению подписи. Сертификат подписи храниться в виде отпечатка ( строка ), но при работе всегда приходиться работать с сертификатом а не с отпечатком ( злобная криптография ), поэтому пусть подпись сразу возвращается с сертификатом, а не с отпечатком ( задача маппера ).
Я описал чем Объекты предметной области могут отличаться от объектов хранилища, а так же отсеиваются заведомо бесполезные операции, такие как запрос подписей. Если надо могу привести еще что ни будь.
Да. Написал ерунду. msdn.microsoft.com/en-us/library/vstudio/ee789835(v=vs.100).aspx
но тот факт, что не для всего есть провайдер (хотя конечно его можно написать при особом желании) (кстати эта особенность возможно только благодаря абстракции), И то что объект домена может сильно отличаться от объекта хранилища, а так же с абстракцией куда удобнее работать и еще много всяких плюсов при работе с Repository и UoW, толкают на реализацию своего DAL в приложении.
Абсолютно верно, так вот именно для этого и нужна. Вот есть контекст данных например MyDbEntities (название так себе)
и теперь везде мы прописываем, что то типа этого
using ( var context = new MyDbEntities() )
и ясно что проект использует не в одном месте доступ к хранилищу.
и что, вот пользователь установил софт, при установке указал какой тип хранения его устраивает.
абстракция? кому нужна абстракция? мы же используем EF который .
без всяких абстракций поддерживает работу с различными движками.
нам в коде всего лишь нужно прописать
If (mode == someOne)
using ( var context = new MyDbEntitiesOne() )
{...}
else
using ( var context = new MyDbEntitiesTwo() )
{...}
а чего, нормальный функционал, за то работает.
я уж не говорю что запросы так же придётся для каждого контекста делать отдельно, т.к. с точки зрения типов даже если полностью совпадает набор полей и методов MyDbEntitiesOne не является MyDbEntitiesTwo
Эм… так я про то и говорю. Что это разные понятия и что для их связи нужен слой который знает про домен и про хранилище ( Repository ).Но некоторые считают ( и это их право )
Data Access Layer в .net уже года три как полностью закрывается EF. Больше ничего писать не нужно.
Я работаю над проектом в котором пользователь сам выбирает где хранить свои данные. И конфигурация DAL происходит при инициализации модуля. Без абстракции это не возможно.
а в некоторых случаях будет вред
от всего может быть вред, если пренебрегать правилами использования. ( касается не только IT сферы, а всего медицины, техники… )
К сожалению не всегда можно описать сущность хранилища что бы она отражала суть предметной области. Так же EF как и любая современная ORM реализует UoW только частично.
Можно увидеть что нибудь живое? Какой нибудь проект в исходниках, класс или что нибудь реальное, что можно попробовать и ощутить. Я повернут на идеальном коде, Фоулере и инверсии управления (которая реально работает, когда приходиться менять функционал, который касается конкретной реализации и не затрагивает абстракцию).
Мощь в том что при работе с объектами предметной области клиента репозитория вообще не интересует ( он этого даже не знает) где, как и в каком виде хранятся данные, он просто формирует запрос в терминах предметной области.
Но это стоит дорого, но оно того стоит.
И вот получена абстракция…
Repository и UoW я о них не писал
так ведь пост изначально был про Specification.
Про выдуманную проблему я описал выше
22 июня 2015 в 15:40
Я описал чем Объекты предметной области могут отличаться от объектов хранилища, а так же отсеиваются заведомо бесполезные операции, такие как запрос подписей. Если надо могу привести еще что ни будь.
но тот факт, что не для всего есть провайдер (хотя конечно его можно написать при особом желании) (кстати эта особенность возможно только благодаря абстракции), И то что объект домена может сильно отличаться от объекта хранилища, а так же с абстракцией куда удобнее работать и еще много всяких плюсов при работе с Repository и UoW, толкают на реализацию своего DAL в приложении.
и теперь везде мы прописываем, что то типа этого
using ( var context = new MyDbEntities() )
и ясно что проект использует не в одном месте доступ к хранилищу.
и что, вот пользователь установил софт, при установке указал какой тип хранения его устраивает.
абстракция? кому нужна абстракция? мы же используем EF который .
нам в коде всего лишь нужно прописать
а чего, нормальный функционал, за то работает.
я уж не говорю что запросы так же придётся для каждого контекста делать отдельно, т.к. с точки зрения типов даже если полностью совпадает набор полей и методов MyDbEntitiesOne не является MyDbEntitiesTwo
в ответ на
от всего может быть вред, если пренебрегать правилами использования. ( касается не только IT сферы, а всего медицины, техники… )
Я полностью согласен с Nagg