Удивляют люди, которые считают, что правильный репозиторий должен выголядить как этот интерфейс

    interface IRepository<T> where T : class
    {
        List<T> GetAll();
        T Find(int entityId);
        T SaveOrUpdate(T entity);
        T Add(T entity);
        T Update(T entity);
        void Delete(T entity);
    }

Это ни что иное, как реализация DAO паттерна. Сам же репозиторий может совершенно не знать о механике и деталях хранения данных (база, файлы, сервис). На маленьких проектах разницу не так сильно видно. А на больших, когда помимо самих запросов, еще необходимо прикрутить кеширование, логирование, фильтрацию по служебным полям, вдруг оказывается, что репозиторий уже совсем не то же, что DAO.
Отсюда и вопросы у новичков, типа, должен ли репозиторий иметь методы GetSomethingByUser, GetUserTickets или просто CRUD не зная про другие репозитории и типы.
А современные фреймворки еще сильнее путают разрабов, реализуя весь Data Access слой. И те, что DAO называли репозиториями начинают думать, что репозитории не нужны, и можно Linq-кодом прошить всю бизнес логику. Даже картинки у Фаулера и на MSDN способствуют тому, что репозиторий воспринимается, главным образом, как провайдер данных, т.е. абстракция над RDBMS, хотя его роль более значимая при проектировании. Возможно, я начитался DDD книжек.

Не кажется ли вам, что пора идею репозитория несколько подправить, чтобы когда один говорил другому этот термин, то оба понимали что-то одно?

Здравствуйте, another_coder, Вы писали:

_>Не кажется ли вам, что пора идею репозитория несколько подправить, чтобы когда один говорил другому этот термин, то оба понимали что-то одно?

Нам кажется, что идею репозитория в отношении БД давно пора похоронить.

Здравствуйте, IT, Вы писали:

IT>Нам кажется, что идею репозитория в отношении БД давно пора похоронить.

А что за класс у нас в проекте, называется Repository?

Здравствуйте, another_coder, Вы писали:

_>Возможно, я начитался DDD книжек.

Если коротко, то domain-driven — это очень здравый и циничный подход к проектированию систем. Ещё раз: про проектирование, про "способ думать", не про реализацию. Т.е. как только очередной эксперт начинает рассказывать про репозитарий на уровне кода, потому что DDD, то можно доставить томик и ласково стучать по башке, предлагать освежить.

ну и далее по тексту

Автор: Sinix
Дата: 15.02.16

.

_>Не кажется ли вам, что пора идею репозитория несколько подправить, чтобы когда один говорил другому этот термин, то оба понимали что-то одно?
Угу, закопать. Как и самый страшный грех архитектора: привычку лепить паттерны без оглядки на инструменты реализации.

Начинать надо с задачи, языка и используемых фреймворков — вот тогда уже можно что-то предметно обсуждать.

13.06.2016 18:58, IT пишет:
> _>Не кажется ли вам, что пора идею репозитория несколько подправить,
> чтобы когда один говорил другому этот термин, то оба понимали что-то одно?
>
> Нам кажется, что идею репозитория в отношении БД давно пора похоронить.

Ура, я такой не один.

--
WBR,
Serge.

Здравствуйте, MozgC, Вы писали:

IT>>Нам кажется, что идею репозитория в отношении БД давно пора похоронить.

MC>А что за класс у нас в проекте, называется Repository?

У нас класс так называется только потому что как-то не придумалось другого названия. Но с предложенным интерфейсом репозитория он не имеет ничего общего. Во-первых, у нас вообще нет никакого интерфейса, потому что он нафиг не нужен. Во-вторых, основная задача нашего класса — возможность тестирования процессов, которые его используют без чтения данных из базы. Т.е. это ближе к DI, чем к паттерну Repository. А здесь репозиторий нужен как часть или даже замена DAO, такой классический пережиток тяжелого прошлого.

Здравствуйте, another_coder, Вы писали:

_>Это ни что иное, как реализация DAO паттерна. Сам же репозиторий может совершенно не знать о механике и деталях хранения данных (база, файлы, сервис). На маленьких проектах разницу не так сильно видно. А на больших, когда помимо самих запросов, еще необходимо прикрутить кеширование, логирование, фильтрацию по служебным полям, вдруг оказывается, что репозиторий уже совсем не то же, что DAO.
_>Отсюда и вопросы у новичков, типа, должен ли репозиторий иметь методы GetSomethingByUser, GetUserTickets или просто CRUD не зная про другие репозитории и типы.

У меня для всех центральных типов, т.е. master в терминологии master-detail есть свой репозиторий и вот там как раз куча вот таких методов GetSomethingByUser, GetSomethingByUser и т.д.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, another_coder, Вы писали:

_>>Не кажется ли вам, что пора идею репозитория несколько подправить, чтобы когда один говорил другому этот термин, то оба понимали что-то одно?

IT>Нам кажется, что идею репозитория в отношении БД давно пора похоронить.

А можно по подробнее(для собственного кругозора)?
По серьезному с данными из базы мы не работаем, в основном редактирование гридов, и есть чуть по сложнее функционал — ну и все.
Простой DataGrid в .NET, очень похож на репозиторий. Хранятся объекты, со статусом Updated/Deleted/Inserted и потом по некой кнопке ОК все это пишется в базу. Это тривиальный кейс, но для редактирования гридов вполне. Если усложнить логику, то что-то делаем, делаем, делаем, потом жмем Save и все ушло в базу (тут конечно можно нарваться на конфликты, но это уже другая тема).

Этот вопрос в сети поднимается довольно часто, но можно поговорить о нем ещё раз.
Во-первых, для репозитория есть достаточно хорошее определение: это коллекция, реализующая долгосрочное хранение однотипных объектов модели предметной области и абстрагирующая пользователя от деталей реализации (=чуть другими словами формулировка Фаулера). Приведенный вами пример полностью соответствует этому определению, поэтому вполне может описывать интерфейс репозитория.
Во-вторых, Фаулер не выделяет отдельно DAO как паттерн и, честно говоря, я не встречал классификации, в которой одновременно существуют оба паттерна, поэтому можно их считать независимыми друг от друга. Если взглянуть например на эту статью, которая описывает DAO так, как его понимают очень многие разработчики, то можно заметить, что DAO это просто компонент слоя доступа к данным, без каких-либо дополнительных определений и условий. Фактически, под определение DAO попадают все паттерны раздела Data Source Architectural Layer отсюда.
Т.е. любой репозиторий — DAO, но не любой DAO — репозиторий.

Далее, вы пишете:
a>А на больших, когда помимо самих запросов, еще необходимо прикрутить кеширование, логирование, фильтрацию по служебным полям, вдруг оказывается, что репозиторий уже совсем не то же, что DAO.
Здесь все смешано в одну большую кучу с неверным заключением. Логика реализации "запросов" (методов, или, как в олдскульном ООП, "сообщений"?), кэширование и логирование — особенности внутренней реализации, о которых клиент не знает. Фильтрация по служебным полям — часть интерфейса DAO (и, как сказано выше, может быть, репозитория) и объекта доменной модели (свойство объекта, которое использует бизнес-логика, является частью доменной модели, поэтому слово "служебный" здесь не имеет особого смысла).

Здравствуйте, IT, Вы писали:
IT>Нам кажется, что идею репозитория в отношении БД давно пора похоронить.
Это почему же?

Здравствуйте, Baudolino, Вы писали:

IT>>Нам кажется, что идею репозитория в отношении БД давно пора похоронить.
B>Это почему же?

Потому что в последние лет 8 появились более продвинутые способы работы с БД.

Здравствуйте, IT, Вы писали:

IT>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
А можно более развернуто? Какие?

Здравствуйте, Baudolino.

В первую очередь, хочу отметить, что речь не о том, что текущие варианты использования неправильные. Речь об изменении парадигмы сознания в отношении репозитория, которая, на мой взгляд, назрела. Назрела потому, что такие разговоры возникают постоянно, являясь следствие неоднозначности этого понятия. Дальше я попробую пояснить используя ваши примеры.

Вы писали:
B>Во-первых, для репозитория есть достаточно хорошее определение: это коллекция, реализующая долгосрочное хранение однотипных объектов модели предметной области и абстрагирующая пользователя от деталей реализации (=чуть другими словами формулировка Фаулера).
В настоящее время, такое определение, на мой взгляд, вводит в заблуждение людей, т.к. является слишком общим. За этим определением может скрываться любой функционал, абсолютно любой. И приведенный пример, действительно, удовлетворяет. Но это не репозиторий.

B>Т.е. любой репозиторий — DAO, но не любой DAO — репозиторий.
Из-за такого представления и возникает путаница в общении. Думаю, следует разделять мух от котлет: DAO — абстракция над хранилищем данным, без логики связанной с бизнесом, Repository — аналогично, как aggregate root в DDD.

Ничего не смешано. Смотрите сами и попробуйте подумать, где вы будете все это сводить в единую систему?
B>Логика реализации "запросов"
Это чистый DAO, или ORM framework.

B>кэширование и логирование — особенности внутренней реализации, о которых клиент не знает.
Это сервисная логика, которая может меняться не зависимо от хранилища по не зависящим от проектирования и ПО хотелкам либо клиента, либо самих разрабов. На каком уровне она будет использоваться?

B>Фильтрация по служебным полям — часть интерфейса DAO (и, как сказано выше, может быть, репозитория)
Служебные поля служебным полям рознь. Есть те, что являются частью бизнес логики, есть те, частью целостности хранения данных, а есть те, что нужны в рамках обслуживания системы. Куда относится, например, IsDeleted (имеется ввиду, что ничего не удаляется), а куда фильтрация по CreatedDate (имеется ввиду, не показывать слишком старые)?

И в дополнение при наличии всего-всего вы начнете думать, как же все это протестировать. Начнете выделять функциональности, чтобы от них изолироваться. Вы обнаружите, что, например, IsDeleted должен быть на уровне DAO, CreatedDate — в Repository, при этом вам 2L кеширование нужно и вы думаете о том, чтобы прицепить 3rd party библиотеку и это тоже нужно в Repsoitory. А вот аудитлог вам скорее всего понадобиться в DAO. Хотя, какую-то умную служебную (алерты для саппорта, например, или для сбора спец информации) нотификацию вы опять же засунете в репозиторй.

Конечно, условий слишком много, чтобы проводить четкую линию между между тем что куда относится. Но то, что хочется видеть, это понимание того, что Data Layer — это не один класс, в который сначала все сваливается, а потом превращается в то, что трудно тестировать и поддерживать. Это должно быть просто и сердито: DAO — объект доступа к данным, Repository — объект подготовки данных к BO. Без всяких обобщений и "перевоплощений" ропозитория в DAO, как вы писали.

И сразу отвечу на возможный вопрос о кеше и доп логике в ропозитории. Нет, она не прошивает его код, а инжектится туда, будучи описанной в других классах. И никак иначе.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, Baudolino.

_>В настоящее время, такое определение, на мой взгляд, вводит в заблуждение людей, т.к. является слишком общим. За этим определением может скрываться любой функционал, абсолютно любой.
Любой, удовлетворяющий определению паттерна. Это нормальная ситуация.

_>И приведенный пример, действительно, удовлетворяет. Но это не репозиторий.
Это репозиторий по определению. Причем по достаточно общепринятому определению. Если вы хотите дать другое определение, давайте, но вам нужно будет объяснить, чем оно лучше.


B>>Т.е. любой репозиторий — DAO, но не любой DAO — репозиторий.
_>Из-за такого представления и возникает путаница в общении.
Путаница в общении обычно возникает из-за того, что кто-то что-то не знает или не понимает. Обычно решается фразой "давай для начала определим, что такое..." и глоссарием в архитектурной документации.

_>Думаю, следует разделять мух от котлет: DAO — абстракция над хранилищем данным, без логики связанной с бизнесом, Repository — аналогично, как aggregate root в DDD.
Вы предлагаете отделять мух от котлет, но используете слова "аналогично" и "как". Хорошее определение не должно использовать аналогии, потому что определение по аналогии нечетко: оно полагается на ментальную модель читателя, которая у разных людей может быть разной. Дайте четкое определение на русском языке и мы его обсудим.

_>Ничего не смешано. Смотрите сами и попробуйте подумать, где вы будете все это сводить в единую систему?
B>>Логика реализации "запросов"
_>Это чистый DAO, или ORM framework.
Что такое "чистый DAO"? Что значит в данном случае "или": если это ORM, то это не DAO? Или DAO=ORM? Как от этого меняется определение репозитория?

B>>кэширование и логирование — особенности внутренней реализации, о которых клиент не знает.
_>Это сервисная логика, которая может меняться не зависимо от хранилища по не зависящим от проектирования и ПО хотелкам либо клиента, либо самих разрабов. На каком уровне она будет использоваться?
Что такое "сервисная логика"? Вспомогательная? Логика сервисного слоя? Кэширование — это алгоритмический, а не архитектурный паттерн. Как реализован ваш компонент доступа к БД — это скрытая деталь реализации. Репозиторий может кэшировать, шлюз БД — может, клиент слоя доступа к данным — может. Суть определений от этого не меняется.

B>>Фильтрация по служебным полям — часть интерфейса DAO (и, как сказано выше, может быть, репозитория)
_>Служебные поля служебным полям рознь. Есть те, что являются частью бизнес логики, есть те, частью целостности хранения данных, а есть те, что нужны в рамках обслуживания системы. Куда относится, например, IsDeleted (имеется ввиду, что ничего не удаляется), а куда фильтрация по CreatedDate (имеется ввиду, не показывать слишком старые)?
Это специфика функциональных требований к конкретной системе, которые нужно как следует анализировать. Давайте разберем на примере IsDeleted. Само по себе такое поле никогда не появляется — оно является частью требований к инфраструктуре приложения, к тому как обрабатываются данные вообще, а не конкретные сущности. Как правило, его задача — сохранить данные для аудита, планового или в чрезвычайной ситуации (для бэкапа такой способ подходит плохо). Для того, чтобы понять, на каком уровне этот флаг появляется, необходимо найти конечного пользователя и используемый им интерфейс. Если это то же самое приложение, то без вариантов — это часть доменной модели и интерфейс DAO знает о его существовании (например, в виде специальных методов типа findDeleted). Если для чтения этого флага используется другое приложение (например, штатный клиент БД) — у вас имеет место быть интеграция через БД, этот флаг является частью протокола интеграции, т.е. особенностью внутренней реализации DAO. При этом все вышесказанное никак не влияет на выбор конкретного вида DAO: это может относиться в равной степени к репозиторию, шлюзу таблицы БД (table data gateway) и т.п.

_>И в дополнение при наличии всего-всего вы начнете думать, как же все это протестировать. Начнете выделять функциональности, чтобы от них изолироваться. Вы обнаружите, что, например, IsDeleted должен быть на уровне DAO, CreatedDate — в Repository, при этом вам 2L кеширование нужно и вы думаете о том, чтобы прицепить 3rd party библиотеку и это тоже нужно в Repsoitory. А вот аудитлог вам скорее всего понадобиться в DAO. Хотя, какую-то умную служебную (алерты для саппорта, например, или для сбора спец информации) нотификацию вы опять же засунете в репозиторй.
Как я уже говорил, в моем представлении репозиторий — это разновидность DAO, и вы пока не предложили альтернативной трактовки. Проблем с тестированием не вижу вообще никаких. Даже со всем, что вы упомянули, тесты (и юнит, и интеграционные) тут будут очень простые. Что меняется от того, что у вас появляется зависимость одного компонента от другого с четко определенным интерфейсом, позволяющим при необходимости в тесте инжектировать заглушку для верификации взаимодействия?

_>Конечно, условий слишком много, чтобы проводить четкую линию между между тем что куда относится. Но то, что хочется видеть, это понимание того, что Data Layer — это не один класс, в который сначала все сваливается, а потом превращается в то, что трудно тестировать и поддерживать.

_>Это должно быть просто и сердито: DAO — объект доступа к данным, Repository — объект подготовки данных к BO. Без всяких обобщений и "перевоплощений" ропозитория в DAO, как вы писали.
Кому должно? Вот тут я, кстати, начал примерно понимать, куда вы клоните. Давайте отбросим на минутку все наши представления о паттернах-фигаттернах, и рассмотрим задачу в общем виде, чтобы определить их заново.
Итак, у нас есть бизнес-логика, реализованная в рамках ООП. Есть хранилище данных, чаще всего реляционное (РСУБД). Нам нужно обеспечить передачу данных из хранилища в бизнес-логику. Поскольку хранилище тяжелое, реализованное посторонними людьми, мы хотим в целях простоты поддержки и тестирования изолировать доступ к нему в отдельном архитектурном слое. Назовем его Data Access Layer (DAL). В этом слое у нас будет некоторое количество компонентов, которые будет использовать бизнес-логика. Следующим шагом мы определим вид этих компонентов, выбрав уровень связности бизнес-логики и хранилища. Если мы готовы пожертвовать гибкостью в пользу большей производительности, мы выбираем интерфейс компонентов, в котором каждый метод представляет собой некий запрос к БД и возвращает временный объект (DTO). Мы называем тип таких компонентов Table Data Gateway. Если мы хотим наоборот, чтобы бизнес-логика воспринимала хранилище просто как некую коллекцию, мы в интерфейсе компонентов DAL будем использовать методы вида добавить/заменить/удалить и назовем такие компоненты Repository. Каждый такой компонент будет соответствовать одной сущности модели (или одной иерархии). Определившись с интерфейсами, приступаем к выбору реализации. Мы будем использовать какое-либо стандартное API для доступа к БД, которое позволит нам выполнять SQL-запросы и получать в ответ табличные данные.
Поскольку нам нужно преобразовать реляционную модель в объектную, нам требуется объектно-реляционное отображение (ORM). Его можно реализовать самостоятельно, строя запросы и преобразуя полученные данные (в таком случае стоит вынести логику построения запросов и чтения результатов в отдельный класс — Object-Relational Mapper), а можно выбрать готовое ORM-решение, которое используя декларативную модель описания отображения, сведет код вашего репозитория к одной строчке в каждом методе.
Далее, хранилище далеко от узла развертывания, поэтому мы хотим ускорить его работу за счет алгоритма кэширования. Мы можем использовать готовый кэш, поэтому добавим в нужные методы компонента DAL попытку чтения из кэша перед чтением из БД. Кэш будет представлен у нас простым интерфейсом с методами вида get/putIfAbsent/invalidate и т.п. За инжектирование конкретной реализации кэша в наш компонент DAL ,будет отвечать контейнер DI. Но лучше всего будет в таком случае настроить кэш в ORM/f и вообще не заморачиваться на собственную реализацию логики. Что касается журналирования и обработки ошибок, замусоривать код такой вспомогательной логикой не обязательно, если у вас есть возможность завернуть ваши компоненты в прокси, которые будут журналировать вызовы методов. Это обычно делается с помощью AOP. А теперь внимание, вопрос: а где здесь собственно должно появиться ваше разделение на "объект доступа к данным" и "объект подготовки данных к ВО"? (и что такое ВО?)


_>И сразу отвечу на возможный вопрос о кеше и доп логике в ропозитории.
А кто бы ставил этот вопрос? Вроде все нормальные люди давно уже используют DI.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Baudolino, Вы писали:

IT>>>Нам кажется, что идею репозитория в отношении БД давно пора похоронить.
B>>Это почему же?

IT>Потому что в последние лет 8 появились более продвинутые способы работы с БД.

А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными? Наверняка как ни будь так:

 class UserCollection
 {
   int Add(User user){}

   void Remove(User user){}

   IEnumerable<User> Find(Specification s){}
 }

Чем не репозиторий? Если при разработке использовать принципы grasp, то репозиторий должен был бы появиться.

Здравствуйте, Qulac, Вы писали:


Q>Чем не репозиторий? Если при разработке использовать принципы grasp, то репозиторий должен был бы появиться.

Кэп: код здорового человека выглядит примерно так:

[Transactional]
void SetRecordData(string code, string data)
{
  var existing = Context.FirstOrDefault<MyRecord>(r => r.Code == code);
  if (data == null)
  {
    existing?.Delete();
  }
  else
  {
    if (existing == null)
    {
       existing = Context.NewObject<MyRecord>(r => r.Code = code);
    }

    existing.Data = data;
  }  
}

Т.е. ноль технических деталей, вся магия под капотом.

Разумеется, код сферический в вакууме, просто чтоб показать основные сценарии. В отдельных случаях может оказаться выгоднее сгенерить sql merge statement, в других — заморочиться с корректной обработкой одновременных update/delete и тыды и тыпы.

Здравствуйте, Qulac, Вы писали:

IT>>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
Q>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
При том, что без БД репозиторий имеет еще меньше смысла.

Если у вас тупо коллекция в памяти, то это List<T>. На крайняк Dictionary<TKey, T>. В нужные моменты времени они сериализуются в файл, а при запуске программы десериализуются из файла.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Qulac, Вы писали:

IT>>>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
Q>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>При том, что без БД репозиторий имеет еще меньше смысла.

G>Если у вас тупо коллекция в памяти, то это List<T>. На крайняк Dictionary<TKey, T>. В нужные моменты времени они сериализуются в файл, а при запуске программы десериализуются из файла.

Не ну это естественно, что внутри нашей коллекции будет List, Dictionary или что то еще подобное. Смысл: у нас ни чего не торчит лишнего через интерфейс, а если какие-то выборки данных повторяются в программе в многих местах, то здесь мы их объедением в нашей коллекции в виде методов. Вся логика работы с данными в одном месте, проще тестировать.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Qulac, Вы писали:


Q>>Чем не репозиторий? Если при разработке использовать принципы grasp, то репозиторий должен был бы появиться.

S>Кэп: код здорового человека выглядит примерно так:
S>

S>[Transactional]
S>void SetRecordData(string code, string data)
S>{
S>  var existing = Context.FirstOrDefault<MyRecord>(r => r.Code == code);
S>  if (data == null)
S>  {
S>    existing?.Delete();
S>  }
S>  else
S>  {
S>    if (existing == null)
S>    {
S>       existing = Context.NewObject<MyRecord>(r => r.Code = code);
S>    }

S>    existing.Data = data;
S>  }  
S>}
S>

S>Т.е. ноль технических деталей, вся магия под капотом.

S>Разумеется, код сферический в вакууме, просто чтоб показать основные сценарии. В отдельных случаях может оказаться выгоднее сгенерить sql merge statement, в других — заморочиться с корректной обработкой одновременных update/delete и тыды и тыпы.

Ну на здоровье как говориться, кому как нравиться.

Здравствуйте, Qulac, Вы писали:

Q>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Qulac, Вы писали:

IT>>>>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
Q>>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>>При том, что без БД репозиторий имеет еще меньше смысла.

G>>Если у вас тупо коллекция в памяти, то это List<T>. На крайняк Dictionary<TKey, T>. В нужные моменты времени они сериализуются в файл, а при запуске программы десериализуются из файла.

Q>Не ну это естественно, что внутри нашей коллекции будет List, Dictionary или что то еще подобное. Смысл: у нас ни чего не торчит лишнего через интерфейс, а если какие-то выборки данных повторяются в программе в многих местах, то здесь мы их объедением в нашей коллекции в виде методов. Вся логика работы с данными в одном месте, проще тестировать.

В List<T> есть лишнее? Логика в разных местах? Вы о чем вообще?
Если вам в программе нужен список людей, например, то зачем городить что-то поверх List<T>?

Вам не надо тестировать List<T>. А если выборки повторяются, то делаете extension-метод для List<Person>.

Здравствуйте, gandjustas, Вы писали:

G>Вам не надо тестировать List<T>. А если выборки повторяются, то делаете extension-метод для List<Person>.

А если ему надо по-разному работать с List<T> (хранилищем) в зависимости от кастомера? Разные выборки без изменения основной логики.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>Вам не надо тестировать List<T>. А если выборки повторяются, то делаете extension-метод для List<Person>.

_>А если ему надо по-разному работать с List<T> (хранилищем) в зависимости от кастомера? Разные выборки без изменения основной логики.

По-разному это как? Приведи пример.

Здравствуйте, gandjustas, Вы писали:

Q>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>При том, что без БД репозиторий имеет еще меньше смысла..
А при чем тут вообще какая-либо конкретная реализация? Списки, БД... почему вы не рассматриваете удаленный веб-сервис, например, в таком случае?
Задача любого архитектурного паттерна — фрагментация сложности. Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов. Repository абстрагирует БД как коллекцию, TDG как объектный интерфейс к таблице, CQRS изолирует отдельные операции и т.д. Архитектурные паттерны — это интерфейсы, реализация которых может быть абсолютно любой. Используя их, вы говорите: клиенту должно быть всё равно, что за этим интерфейсом, пока они соблюдают контракт. Изменения в реализации, например, оптимизации производительности или журналирование, надежно скрыты за этим контрактом и не ломают клиентский код.
Реализация в виде хранилища в памяти тут просто удобная плюшка для ранних этапов разработки и юнит-тестов.

Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

Q>>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>>При том, что без БД репозиторий имеет еще меньше смысла..
B>А при чем тут вообще какая-либо конкретная реализация? Списки, БД... почему вы не рассматриваете удаленный веб-сервис, например, в таком случае?
Потому что с веб-сервисом, базой данных и списком в памяти работа ведется совершенно по-разному.
1) Список в памяти можно обойти весь оператором foreach
2) К веб-сервису можно сделать запрос с определенными параметрами
3) К базе можно сделать SQL запрос, а еще она поддерживает транзакции.

Как вы эти три принципиально разные операции спрячете за одним универсальным интерфейсом?

В C# кстати придумали такой универсальный интерфейс — linq запросы. Но свой linq провайдер мало кто пишет, пользуется готовыми.
Вот и ответ на вопрос почему паттерн Repository бесполезен в наше время.


B>Задача любого архитектурного паттерна — фрагментация сложности. Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.
Обычная функциональная декомпозиция тоже занимается фрагметацией сложности. Для этого не нужно создавать отдельные сущности и паттерны.
И вообще никто не говорит, что надо в батонклике вызывать SqlCommand. Нужно использовать функциональную декомпозицию.

B>Repository абстрагирует БД как коллекцию
Это первая и главная ошибка. Коллекцция объектов в памяти и таблица в БД обладают принципиально разными свойствами с точки зрения кода, даже если можно их свести к одному интерфейсу.


B>Архитектурные паттерны — это интерфейсы, реализация которых может быть абсолютно любой.
Не может, у них контракты разные. См выше.

B>Изменения в реализации, например, оптимизации производительности или журналирование, надежно скрыты за этим контрактом и не ломают клиентский код.
Для этого снова не нужен репозиторий как паттерн.

B>Реализация в виде хранилища в памяти тут просто удобная плюшка для ранних этапов разработки и юнит-тестов.
Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Qulac, Вы писали:

Q>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Qulac, Вы писали:

IT>>>>>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
Q>>>>А причем тут БД, а если нужно хранить данные просто в памяти, а для хранения скидывать их в файл через серелизацию, как тогда организовывать работу с данными?
G>>>При том, что без БД репозиторий имеет еще меньше смысла.

G>>>Если у вас тупо коллекция в памяти, то это List<T>. На крайняк Dictionary<TKey, T>. В нужные моменты времени они сериализуются в файл, а при запуске программы десериализуются из файла.

Q>>Не ну это естественно, что внутри нашей коллекции будет List, Dictionary или что то еще подобное. Смысл: у нас ни чего не торчит лишнего через интерфейс, а если какие-то выборки данных повторяются в программе в многих местах, то здесь мы их объедением в нашей коллекции в виде методов. Вся логика работы с данными в одном месте, проще тестировать.

G>В List<T> есть лишнее? Логика в разных местах? Вы о чем вообще?
G>Если вам в программе нужен список людей, например, то зачем городить что-то поверх List<T>?

Зачем вообще тогда нужна архитектура по, разделение интерфейсов и прочее, прочее. Мы ведь про архитектуру говорим или нет? Тогда вообще ни чего не нужно, можно писать как бог на душу положит.

G>Вам не надо тестировать List<T>. А если выборки повторяются, то делаете extension-метод для List<Person>.

Это частный случай решения проблемы, он не решает проблему слишком широкого интерфейса list, кто муже есть не во всех языках.

Здравствуйте, Qulac, Вы писали:

G>>В List<T> есть лишнее? Логика в разных местах? Вы о чем вообще?
G>>Если вам в программе нужен список людей, например, то зачем городить что-то поверх List<T>?

Q>Зачем вообще тогда нужна архитектура по, разделение интерфейсов и прочее, прочее. Мы ведь про архитектуру говорим или нет? Тогда вообще ни чего не нужно, можно писать как бог на душу положит.

Архитектура это не тогда, когда много паттернов, а когда сделано ровно столько, сколько нужно, чтобы решить задачу и не изобретать велосипеды.

G>>Вам не надо тестировать List<T>. А если выборки повторяются, то делаете extension-метод для List<Person>.
Q>Это частный случай решения проблемы, он не решает проблему слишком широкого интерфейса list, кто муже есть не во всех языках.
А в чем интерфейс List слишком широк? И почему это вообще должно быть проблемой?

Здравствуйте, gandjustas.

На мой взгляд, вы не разделяете сущности от их технической реализации. В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service). Весь функционал, который относится к доступу к данным спрятан там же и наружу не показывается. И вот тут как раз приходин на помощь объект, представляющий собой DAO. Конкретная его реализация может быть разной и зависить от уровня закладываемой абстракции в архитектуру. Это может быть EF, а может быть и просто объект с простым CRUD интерфейсом.

Вам это описание понятно?

В тексте Вы постоянно подразумеваете конкретную техническую реализацию, хотя это, в данным случае, не имеет значения.

Здравствуйте, gandjustas, Вы писали:

G>По-разному это как? Приведи пример.

Ну например, 1 выбирает по одному флагу, 2й выбирает по двум. Система мультитенант, и логика работы определяется динамически. Хранилище у всех IList.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, gandjustas.

_>На мой взгляд, вы не разделяете сущности от их технической реализации. В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service). Весь функционал, который относится к доступу к данным спрятан там же и наружу не показывается. И вот тут как раз приходин на помощь объект, представляющий собой DAO. Конкретная его реализация может быть разной и зависить от уровня закладываемой абстракции в архитектуру. Это может быть EF, а может быть и просто объект с простым CRUD интерфейсом.

Ок, давайте конкретнее. Пусть у вас есть "хранилище данных" сотрудников.
Фактически это будет три разных хранилища:
1) Список в памяти — List<T>
2) База данных
3) Веб-сервис, который имеет только методы получения и сохранения по ID.

У вас задача поднять сотрудникам определенной категории зарплату на 10%.

Какой интерфейс универсального "хранилища данных" вы спроектируете для решения этой задачи.
Естественно писать заведомо неэффективный код — моветон.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>По-разному это как? Приведи пример.

_>Ну например, 1 выбирает по одному флагу, 2й выбирает по двум. Система мультитенант, и логика работы определяется динамически. Хранилище у всех IList.
Сделать две функции не?

Здравствуйте, gandjustas, Вы писали:

G>Как вы эти три принципиально разные операции спрячете за одним универсальным интерфейсом?
Есть такое слово "абстракция", знаете? Давайте вспомним его определение: абстракция — это техника анализа, в которой выявляются существенные аспекты, а несущественные исключаются. Как работает абстракция в объектно-ориентированном анализе? Вы определяете аспекты поведения объекта, существенные для клиента, скрывая (инкапсулируя) детали, для него не существенные. Как это работает в случае с паттерном "репозиторий" на примере упомянутых вами операций?
1. Клиенту нужен foreach: репозиторий должен уметь возвращать итератор по хранящимся в нем объектам. Это может быть реализовано за счет обращения к хранилищу и кэширования результатов для оптимизации производительности. Если хранилище — область оперативной памяти, кэш не требуется, если удаленный сервис или СУБД — можно вычитывать блоки данных и сохранять в кэш.
2. Клиенту нужен поиск по параметрам: репозиторий должен предоставлять метод поиска с параметрами. Реализация будет строить фильтр или формировать запрос к хранилищу — вариантов много.
3. Клиенту нужна транзакционность: ок, но это обычно делается на уровне бизнес-логики (менеджер транзакций должен использовать общие сессии вместе со всеми транзакционными службами, не только с репозиториями, но и, например, очередями). Если вдруг вы решили все же сделать поддержку транзакций частью репозитория, придется, разумеется реализовывать ее логику.

G>В C# кстати придумали такой универсальный интерфейс — linq запросы. Но свой linq провайдер мало кто пишет, пользуется готовыми.
G>Вот и ответ на вопрос почему паттерн Repository бесполезен в наше время.
LINQ представляет собой удобный интерфейс описания возможных запросов к объектам. В случае с БД, таким объектом является компонент DAL, если точнее — ORM.
Факт существования LINQ, вообще говоря, ничего не означает.

B>>Задача любого архитектурного паттерна — фрагментация сложности. Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.
G>Обычная функциональная декомпозиция тоже занимается фрагметацией сложности. Для этого не нужно создавать отдельные сущности и паттерны.
Паттерны стандартизируют такую декомпозицию, предлагая типовой подход к решению типовых задач. Отказываться от их использования там, где оно оправдано, — изобретать ненужный велосипед.

B>>Repository абстрагирует БД как коллекцию
G>Это первая и главная ошибка. Коллекцция объектов в памяти и таблица в БД обладают принципиально разными свойствами с точки зрения кода, даже если можно их свести к одному интерфейсу.
С точки зрения сферического коня в вакууме возможно всё. С точки зрения конкретного клиентского кода принципиальных различий может и не быть.


B>>Архитектурные паттерны — это интерфейсы, реализация которых может быть абсолютно любой.
G>Не может, у них контракты разные.
Контракт определяет интерфейс, а не его реализация. Реализация обязана соблюдать контракт по определению.

B>>Реализация в виде хранилища в памяти тут просто удобная плюшка для ранних этапов разработки и юнит-тестов.
G>Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные.
У вас десять классов, работающих с хранилищем объектов типа А. Что проще — поменять в одном месте реализацию интерфейса хранилища объектов, или поменять во всех местах работу с ним со списка на что-то иное?

P.S. Давайте для более конструктивного разговора уточним позиции. Я не утверждаю, что репозиторий нужен всегда — скорее, я имею в виду, что у этого паттерна есть смысл и область применения, поэтому утверждение что он "не нужен вообще" не является истинным и связано, скорее, с непониманием этого смысла и области применения.

Здравствуйте, gandjustas, Вы писали:


Q>>Зачем вообще тогда нужна архитектура по, разделение интерфейсов и прочее, прочее. Мы ведь про архитектуру говорим или нет? Тогда вообще ни чего не нужно, можно писать как бог на душу положит.

G>Архитектура это не тогда, когда много паттернов, а когда сделано ровно столько, сколько нужно, чтобы решить задачу и не изобретать велосипеды.

Для этого и придуманы паттерны. Современная архитектура -- это взаимодействие паттерноподобных сущностей, абстракций. А гофосккие паттерны -- платоновский идеал.

Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

G>>Как вы эти три принципиально разные операции спрячете за одним универсальным интерфейсом?
B>Есть такое слово "абстракция", знаете? Давайте вспомним его определение: абстракция — это техника анализа, в которой выявляются существенные аспекты, а несущественные исключаются.
Вы несущественными не то объявили.
Несущественные различия это делать Repository или extension-методы для List<T>. Это различие не влияет на характеристики программы.
А тип источника данных очень сильно влияет.


B>1. Клиенту нужен foreach: репозиторий должен уметь возвращать итератор по хранящимся в нем объектам. Это может быть реализовано за счет обращения к хранилищу и кэширования результатов для оптимизации производительности. Если хранилище — область оперативной памяти, кэш не требуется, если удаленный сервис или СУБД — можно вычитывать блоки данных и сохранять в кэш.
B>2. Клиенту нужен поиск по параметрам: репозиторий должен предоставлять метод поиска с параметрами. Реализация будет строить фильтр или формировать запрос к хранилищу — вариантов много.
B>3. Клиенту нужна транзакционность: ок, но это обычно делается на уровне бизнес-логики (менеджер транзакций должен использовать общие сессии вместе со всеми транзакционными службами, не только с репозиториями, но и, например, очередями). Если вдруг вы решили все же сделать поддержку транзакций частью репозитория, придется, разумеется реализовывать ее логику.
Отлично — у вас есть веб-сервис, обычный web api с Get и Post по ключу. А вы напроектировани репозиторий с поиском по параметрам. Что дальше делать?
И стоило его изначально таким делать?

G>>В C# кстати придумали такой универсальный интерфейс — linq запросы. Но свой linq провайдер мало кто пишет, пользуется готовыми.
G>>Вот и ответ на вопрос почему паттерн Repository бесполезен в наше время.
B>LINQ представляет собой удобный интерфейс описания возможных запросов к объектам. В случае с БД, таким объектом является компонент DAL, если точнее — ORM.
B>Факт существования LINQ, вообще говоря, ничего не означает.
Факт существования ORM_ов c поддержкой Linq означает. Потому что Linq может за одинаковым интерфейсом скрыть и список в памяти, и веб-сервисы (с ограничениями) и базы данных.
Но писать такое с нуля для одного приложения никто не будет, надо пользоваться готовым. Поэтому паттерн repository категорически не в тему, надо пользоваться orm.


B>>>Задача любого архитектурного паттерна — фрагментация сложности. Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.
G>>Обычная функциональная декомпозиция тоже занимается фрагметацией сложности. Для этого не нужно создавать отдельные сущности и паттерны.
B>Паттерны стандартизируют такую декомпозицию, предлагая типовой подход к решению типовых задач. Отказываться от их использования там, где оно оправдано, — изобретать ненужный велосипед.
Repository сам по себе велосипед при наличии ORM.
Вы еще докажите оправданность репозитория по сравнению с обычной декомпозицией.

B>>>Repository абстрагирует БД как коллекцию
G>>Это первая и главная ошибка. Коллекцция объектов в памяти и таблица в БД обладают принципиально разными свойствами с точки зрения кода, даже если можно их свести к одному интерфейсу.
B>С точки зрения сферического коня в вакууме возможно всё. С точки зрения конкретного клиентского кода принципиальных различий может и не быть.
Принципиальное различие в скорости работы. Как только вызовы начинают пересекать граници процесса надо внимательно следить как часто происходят обращения и сколько данных передается. Иначе получается тормозное говно.
И это тоже часть архитектуры. Причем гораздо более важная, чем паттерны.


B>>>Архитектурные паттерны — это интерфейсы, реализация которых может быть абсолютно любой.
G>>Не может, у них контракты разные.
B>Контракт определяет интерфейс, а не его реализация.
Ты чего сейчас сказал?
Контрат шире чем интерфейс. Например интерфейс не может описать сайд-эффекты.
Для ORMов контракт обычно такой — ты работает с коллекцией объектов в памяти, а потом вызываешь функцию сохранения изменений в БД. В интерфейсе сохранение никак не фигурирует. И ты можешь ошибочно подумать, что таблица в базе эквивалентна List<T>, хотя это совсем не так.


B>>>Реализация в виде хранилища в памяти тут просто удобная плюшка для ранних этапов разработки и юнит-тестов.
G>>Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные.
B>У вас десять классов, работающих с хранилищем объектов типа А. Что проще — поменять в одном месте реализацию интерфейса хранилища объектов, или поменять во всех местах работу с ним со списка на что-то иное?
Кто тебе сказал про десятки классов?

B>P.S. Давайте для более конструктивного разговора уточним позиции. Я не утверждаю, что репозиторий нужен всегда — скорее, я имею в виду, что у этого паттерна есть смысл и область применения, поэтому утверждение что он "не нужен вообще" не является истинным и связано, скорее, с непониманием этого смысла и области применения.
Я утверждаю, что у этого паттерна нет области применения, потому что для БД есть ORM, а для остальных случаев repository не подходит.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:


Q>>>Зачем вообще тогда нужна архитектура по, разделение интерфейсов и прочее, прочее. Мы ведь про архитектуру говорим или нет? Тогда вообще ни чего не нужно, можно писать как бог на душу положит.
G>>Архитектура это не тогда, когда много паттернов, а когда сделано ровно столько, сколько нужно, чтобы решить задачу и не изобретать велосипеды.
S>Для этого и придуманы паттерны. Современная архитектура -- это взаимодействие паттерноподобных сущностей, абстракций. А гофосккие паттерны -- платоновский идеал.
Для этого придуманы библиотеки и компоненты, а паттерны нужны когда готовых средств нет.
Но огромное количество программистов вместо использования готового лепят паттерны, а потом в них заворачивают готовые компоненты, так как свою реализацию написать не способны и называют это архитектурой.

Здравствуйте, gandjustas, Вы писали:


S>>Для этого и придуманы паттерны. Современная архитектура -- это взаимодействие паттерноподобных сущностей, абстракций. А гофосккие паттерны -- платоновский идеал.
G>Для этого придуманы библиотеки и компоненты, а паттерны нужны когда готовых средств нет.

Пол-правды. Заиграть вместе придуманные библиотеки и компоненты тоже надо. Вот тут многие паттерны и пригождаются.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:


S>>>Для этого и придуманы паттерны. Современная архитектура -- это взаимодействие паттерноподобных сущностей, абстракций. А гофосккие паттерны -- платоновский идеал.
G>>Для этого придуманы библиотеки и компоненты, а паттерны нужны когда готовых средств нет.
S>Пол-правды. Заиграть вместе придуманные библиотеки и компоненты тоже надо. Вот тут многие паттерны и пригождаются.
Но не repository, о нем же разговор, не?

Здравствуйте, Sharov, Вы писали:

S>Пол-правды. Заиграть вместе придуманные библиотеки и компоненты тоже надо. Вот тут многие паттерны и пригождаются.
Из практики — наоборот.

Хорошие библиотеки просто подключаются и используются. А вот если автор был укушен Фаулером, то без костылей, которые превращают сфероконину в рабочий код, не обойтись.

Я ещё не видел ни одного случая, когда дизайн "от паттернов" не разбивался бы вдребезги при попытке реального использования. Даже если общий дизайн отлично продуман и за идеями есть солидный бэкграунд, всё равно даже простейшие вещи неизбежно требуют обкладывания хелперами.
Желающие поспорить могут посмотреть на популярность Rx, TPL DataFlow или CodeContracts.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Пол-правды. Заиграть вместе придуманные библиотеки и компоненты тоже надо. Вот тут многие паттерны и пригождаются.
S>Из практики — наоборот.

"Многие паттерны" следует заменить на "некоторые паттерны", согласен. Архитектуры бывают разные и иногда это не просто подключил 10 сторонних библиотек и используешь.

S>Хорошие библиотеки просто подключаются и используются. А вот если автор был укушен Фаулером, то без костылей, которые превращают сфероконину в рабочий код, не обойтись.

1)Архитектуры бывают разные и иногда это не просто подключил 10 сторонних библиотек и используешь.
2)Библиотеки, за исключением базовых типа io, маршалинга, синх. примитиовов и проч. не из воздуха берутся.

S>Я ещё не видел ни одного случая, когда дизайн "от паттернов" не разбивался бы вдребезги при попытке реального использования. Даже если общий дизайн отлично продуман и за идеями есть солидный бэкграунд, всё равно даже простейшие вещи неизбежно требуют обкладывания хелперами.

Это уже здесь обсуждалось раз 100500. Я ни в коем случае(!!!) не призываю разрабатывать от паттернов. Но. Это типовые решения -- раз, это некоторый язык общения разработчиков -- два. А mvc это вообще основа всех основ. На этом форуме все это обсуждалось 3-4 года назад и хватит.

S>Желающие поспорить могут посмотреть на популярность Rx, TPL DataFlow или CodeContracts.

Если я правильно понял Ваш посыл, то:
1) этот список можно долго дополнять;
2) смысл сравнивать слабый маркетинг и инженерные решения?

Если было бы надо, ms на силу впарило бы это все. Желания не було. Вот можно подумать win32 гений инженерной мысли, однако люди-то пользовались.


ЗЫ:Вот я это написал, и как водится перечитал сообщения на которое отвечаю -- что в этом списке делает TPL, у него вроде все неплохо? Я точно правильно понял Ваш посыл?

Здравствуйте, Sharov, Вы писали:

S>Это уже здесь обсуждалось раз 100500. Я ни в коем случае(!!!) не призываю разрабатывать от паттернов. Но. Это типовые решения -- раз, это некоторый язык общения разработчиков -- два. А mvc это вообще основа всех основ. На этом форуме все это обсуждалось 3-4 года назад и хватит.
Аминь!

Здравствуйте, Sharov, Вы писали:

S>1)Архитектуры бывают разные и иногда это не просто подключил 10 сторонних библиотек и используешь.
Если библиотеку писали люди, осилившие FDG — именно что подключается и используется. Посмотри на сам фреймворк — полно отличных примеров и хорошего дизайна, и хорошего, но перенавороченного. А вот примеры из разряда "не делайте так вообще" по пальцам пересчитать можно и в основном это или наследство от fw 1.0 или последствия попытки поиграть в "мы модные и современные" с .Net Core.


S>2)Библиотеки, за исключением базовых типа io, маршалинга, синх. примитиовов и проч. не из воздуха берутся.
Да ладно. Публичное API, если его вообще делают целенаправленно, а не постфактум — именно что набор хороших идей с других похожих библиотек + правки по опыту догфудинга. Проблемы в основном возникают, когда решения перетягиваются в лоб с других платформ людьми, которые дотнет знают слабовато. Вот тогда да — обнять и плакать


S>>Желающие поспорить могут посмотреть на популярность Rx, TPL DataFlow или CodeContracts.

S>Если я правильно понял Ваш посыл, то:
S>2) смысл сравнивать слабый маркетинг и инженерные решения?

Не, я именно про удобство использования — все вышеперечисленные требуют держать в голове ментальную модель самой библиотеки (местами крайне нелогичную) и пересказывать свои хотелки в терминах этой модели. Что ставит однозначный крест на сколько-нибудь широком использовании.
Ради справедливости, Rx сам по себе очень даже неплох, а свежие версии Code Contracts в принципе почти пригодны к использованию в продакшне. Но задел на старте что там, что там был прокакан (пардон мой французский) прям образцово. А проблема всё та же, что сейчас с .Net Core — внезапно™ выяснилось, что идея забить на реальные сценарии использования немножко не работает.


S>Если было бы надо, ms на силу впарило бы это все. Желания не було. Вот можно подумать win32 гений инженерной мысли, однако люди-то пользовались.
Угу. И сколько таких мазохистов осталось после появления хоть какой-то альтернативы?


S>ЗЫ:Вот я это написал, и как водится перечитал сообщения на которое отвечаю -- что в этом списке делает TPL, у него вроде все неплохо? Я точно правильно понял Ваш посыл?
Не TPL, а TPL Dataflow. У них своя атмосфера

Здравствуйте, Qulac, Вы писали:

Q>А причем тут БД,

БД при этой теме. Можно посмотреть на заголовок. А сериализовать, да, можно.

Здравствуйте, Baudolino, Вы писали:

IT>>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
B>А можно более развернуто? Какие?

Большие дяди в последнее время используют исключительно LINQ.

Здравствуйте, Qulac, Вы писали:

Q>Зачем вообще тогда нужна архитектура по, разделение интерфейсов и прочее, прочее. Мы ведь про архитектуру говорим или нет?

А зачем нужна архитектура и интерфейсы? Для ответа на этот вопрос есть другой более конкретный вопрос для каждого конкретного случая:

— Какую проблему решает конкретное разделение интерфейсов, конкретное прочее и конкретное другое прочее?

Часто оказывается, что разделение на интерфейсы делается только ради архитектуры и ничего другого. И тогда мы задаём первоначальный вопрос:

— А зачем нужна такая архитектура?

Q>Тогда вообще ни чего не нужно, можно писать как бог на душу положит.

Попробуй. Хорошо писать как бог на душу положит мало у кого получается. Это вывсшее дао программирования. Я пока таких людей не встречал.

Здравствуйте, another_coder, Вы писали:

_>В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service).

Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>1)Архитектуры бывают разные и иногда это не просто подключил 10 сторонних библиотек и используешь.
S>Если библиотеку писали люди, осилившие FDG — именно что подключается и используется. Посмотри на сам фреймворк — полно отличных примеров и хорошего дизайна, и хорошего, но перенавороченного. А вот примеры из разряда "не делайте так вообще" по пальцам пересчитать можно и в основном это или наследство от fw 1.0 или последствия попытки поиграть в "мы модные и современные" с .Net Core.

Сам фреймворк между прочим и есть базовая библиотека. Там воленс-ноленс сложных решений быть не должно. С архитектурной точки зрения.


S>>2)Библиотеки, за исключением базовых типа io, маршалинга, синх. примитиовов и проч. не из воздуха берутся.
S>Да ладно. Публичное API, если его вообще делают целенаправленно, а не постфактум — именно что набор хороших идей с других похожих библиотек + правки по опыту догфудинга. Проблемы в основном возникают, когда решения перетягиваются в лоб с других платформ людьми, которые дотнет знают слабовато. Вот тогда да — обнять и плакать

Не понял куда опять дискуссия зашла Все мало-мальски серьезные приложения используют кучу библиотек в императивном стиле штоле? Типа:
библиотека1.вызов1()
библиотека2.вызов3()
библиотека1.вызов2()
...

Или же идет оркестрации на несколько более абстрактному уровне. Т.е. если исп. стороннюю библиотеку или компонент, то паттерны ни-ни. Судя по дискуссии получается так. Я не вижу проблем использовать паттерны и сторонние компоненты, если речь об этом.

S>>>Желающие поспорить могут посмотреть на популярность Rx, TPL DataFlow или CodeContracts.

S>>Если я правильно понял Ваш посыл, то:
S>>2) смысл сравнивать слабый маркетинг и инженерные решения?

S>Не, я именно про удобство использования — все вышеперечисленные требуют держать в голове ментальную модель самой библиотеки (местами крайне нелогичную) и пересказывать свои хотелки в терминах этой модели. Что ставит однозначный крест на сколько-нибудь широком использовании.
S>Ради справедливости, Rx сам по себе очень даже неплох, а свежие версии Code Contracts в принципе почти пригодны к использованию в продакшне. Но задел на старте что там, что там был прокакан (пардон мой французский) прям образцово. А проблема всё та же, что сейчас с .Net Core — внезапно™ выяснилось, что идея забить на реальные сценарии использования немножко не работает.

S>>ЗЫ:Вот я это написал, и как водится перечитал сообщения на которое отвечаю -- что в этом списке делает TPL, у него вроде все неплохо? Я точно правильно понял Ваш посыл?
S>Не TPL, а TPL Dataflow. У них своя атмосфера

Я думал это пример не взлетевших фреймворков.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, another_coder, Вы писали:

_>>В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service).

IT>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?

Парочка найдется.

Здравствуйте, IT, Вы писали:

IT>Большие дяди в последнее время используют исключительно LINQ.
Между нами, большими дядями, LINQ существует только на одной, причем не самой популярной платформе.

Здравствуйте, gandjustas, Вы писали:

G>Вы несущественными не то объявили.
G>Несущественные различия это делать Repository или extension-методы для List<T>. Это различие не влияет на характеристики программы.
G>А тип источника данных очень сильно влияет.
Начнем с того, что я несущественным ничего не объявлял. Я продемонстрировал, как детали реализации могут быть скрыты в определенных ситуациях, но я не утверждал, что это всегда возможно. Вы понимаете различие между словами "существует" и "всегда"? А их отрицание построить можете и применить к нашему разговору?

G>Отлично — у вас есть веб-сервис, обычный web api с Get и Post по ключу. А вы напроектировани репозиторий с поиском по параметрам. Что дальше делать?
G>И стоило его изначально таким делать?
Думаю, стоит начать с того, что это "напроектировали" вы, а не я. Я не натягиваю паттерны на сферических коней.

G>Но писать такое с нуля для одного приложения никто не будет, надо пользоваться готовым. Поэтому паттерн repository категорически не в тему, надо пользоваться orm.
Ваша категоричность пока что голословна.

G>Repository сам по себе велосипед при наличии ORM.
А LINQ это, по-вашему, ORM? И, кстати, сколько разных ORM вы знаете (в смысле использовали)? На каких платформах?

G>Принципиальное различие в скорости работы. Как только вызовы начинают пересекать граници процесса надо внимательно следить как часто происходят обращения и сколько данных передается. Иначе получается тормозное говно.
G>И это тоже часть архитектуры. Причем гораздо более важная, чем паттерны.
Термин "преждевременная оптимизация" знаком? Где вы увидели пересечение "границ процесса" при реализации паттерна?

B>>Контракт определяет интерфейс, а не его реализация.
G>Ты чего сейчас сказал?
G>Контрат шире чем интерфейс. Например интерфейс не может описать сайд-эффекты.
Интерфейс не должен описывать побочные эффекты. С точки зрения пользователя интерфейса побочных эффектов не должно существовать — это аксиома ООП, которую самое время выучить.

G>Для ORMов контракт обычно такой — ты работает с коллекцией объектов в памяти, а потом вызываешь функцию сохранения изменений в БД. В интерфейсе сохранение никак не фигурирует.
Функция сохранения изменений в БД — часть интерфейса.

G>И ты можешь ошибочно подумать, что таблица в базе эквивалентна List<T>, хотя это совсем не так.
Вы всё время делаете какие-то очень странные и ничем не обоснованные суждения насчёт того, как я думаю, и выдаёте необоснованные отрицания достойные включения в "Женскую логику" Беклемишева в качестве примера отвергнутых аргументов. Предложение: вместо того, чтобы использовать фразы типа "это совсем не так", вы будете с этого момента для продолжения дискуссии аргументировать, почему не так, в каких обстоятельствах?

G>>>Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные.
B>>У вас десять классов, работающих с хранилищем объектов типа А. Что проще — поменять в одном месте реализацию интерфейса хранилища объектов, или поменять во всех местах работу с ним со списка на что-то иное?
G>Кто тебе сказал про десятки классов?
Допустим, у вас примерно десять классов... Рядовая ситуация на крупном проекте.

Здравствуйте, Baudolino, Вы писали:

B>Здравствуйте, gandjustas, Вы писали:

G>>Вы несущественными не то объявили.
G>>Несущественные различия это делать Repository или extension-методы для List<T>. Это различие не влияет на характеристики программы.
G>>А тип источника данных очень сильно влияет.
B>Начнем с того, что я несущественным ничего не объявлял. Я продемонстрировал, как детали реализации могут быть скрыты в определенных ситуациях, но я не утверждал, что это всегда возможно. Вы понимаете различие между словами "существует" и "всегда"? А их отрицание построить можете и применить к нашему разговору?
Что сказать-то хотел?

G>>Отлично — у вас есть веб-сервис, обычный web api с Get и Post по ключу. А вы напроектировани репозиторий с поиском по параметрам. Что дальше делать?
G>>И стоило его изначально таким делать?
B>Думаю, стоит начать с того, что это "напроектировали" вы, а не я. Я не натягиваю паттерны на сферических коней.
То есть вам таки важно какой источник данных? Тогда зачем repository?

G>>Но писать такое с нуля для одного приложения никто не будет, надо пользоваться готовым. Поэтому паттерн repository категорически не в тему, надо пользоваться orm.
B>Ваша категоричность пока что голословна.
То есть объективных причин использовать repository нет?

G>>Repository сам по себе велосипед при наличии ORM.
B>А LINQ это, по-вашему, ORM?
По нашему linq это query object, а ORM это linq-провайдер, он же repository в определении Фаулера.

B>И, кстати, сколько разных ORM вы знаете (в смысле использовали)? На каких платформах?
Использовал EF, Linq2DB, Nhibernate, linq2sql на C#, FSharp.Data, Hibernate на java, а также писал свои ORM на Delphi, C# и C++.


G>>Принципиальное различие в скорости работы. Как только вызовы начинают пересекать граници процесса надо внимательно следить как часто происходят обращения и сколько данных передается. Иначе получается тормозное говно.
G>>И это тоже часть архитектуры. Причем гораздо более важная, чем паттерны.
B>Термин "преждевременная оптимизация" знаком? Где вы увидели пересечение "границ процесса" при реализации паттерна?
Мне знаком термин преждевременная пессимизация. Когда в угоду паттернам код пишется на порядок более медленным, чем он мог бы быть.
Пересечение границ процесса случается чуть менее чем в каждом случае, кроме хранилища в памяти. А каждый второй писать repository проектирует его, как будто это просто коллекция в памяти. Вот и получается пессимизация, которую уже крайне сложно поправить.

B>>>Контракт определяет интерфейс, а не его реализация.
G>>Ты чего сейчас сказал?
G>>Контрат шире чем интерфейс. Например интерфейс не может описать сайд-эффекты.
B>Интерфейс не должен описывать побочные эффекты. С точки зрения пользователя интерфейса побочных эффектов не должно существовать — это аксиома ООП, которую самое время выучить.
Дай ссылку на того, кто эту аксиому доказал. Мне кажется ты ООП с ФП путаешь и то неверно понимаешь побочные эффекты в ФП.
Алан Кей и Бертран Мейер как раз в своих определениях ООП опираются на побочные эффекты при взаимодействии с объектами.

G>>Для ORMов контракт обычно такой — ты работает с коллекцией объектов в памяти, а потом вызываешь функцию сохранения изменений в БД. В интерфейсе сохранение никак не фигурирует.
B>Функция сохранения изменений в БД — часть интерфейса.
Точно? А если у нас таки коллекция в памяти? Или веб-сервис?

G>>И ты можешь ошибочно подумать, что таблица в базе эквивалентна List<T>, хотя это совсем не так.
B>Вы всё время делаете какие-то очень странные и ничем не обоснованные суждения насчёт того, как я думаю, и выдаёте необоснованные отрицания достойные включения в "Женскую логику" Беклемишева в качестве примера отвергнутых аргументов. Предложение: вместо того, чтобы использовать фразы типа "это совсем не так", вы будете с этого момента для продолжения дискуссии аргументировать, почему не так, в каких обстоятельствах?
Мне приходится озвучивать твои мысли, потому что ты их не озвучиваешь и общаешься полунамеками. Я уже перестал понимать какую позицию ты пытаешься отстоять.

G>>>>Само по себе добавление репозитория на ранних этапах — бесполезное усложнение кода. Можно банально обращаться к статическим спискам в памяти пока не появится необходимость сохранять данные.
B>>>У вас десять классов, работающих с хранилищем объектов типа А. Что проще — поменять в одном месте реализацию интерфейса хранилища объектов, или поменять во всех местах работу с ним со списка на что-то иное?
G>>Кто тебе сказал про десятки классов?
B>Допустим, у вас примерно десять классов... Рядовая ситуация на крупном проекте.
И что? Какую задачу мы решаем?

Здравствуйте, another_coder, Вы писали:

IT>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
_>Парочка найдется.

Расскажи про них.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, another_coder, Вы писали:

IT>>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
_>>Парочка найдется.

G>Расскажи про них.

После вас. Только не забудьте привести архитектуру с коментами почему именно такое решение было принято. Более не вижу смысла продолжать этот тред, т.к. оффтоп.

G>Дай ссылку на того, кто эту аксиому доказал.
Я пожалуй закончу наш разговор на этой чудесной цитате.

Здравствуйте, Baudolino, Вы писали:

G>>Дай ссылку на того, кто эту аксиому доказал.
B>Я пожалуй закончу наш разговор на этой чудесной цитате.

Ах, простите, неверно выразился.

Приведите ссылку на общеизвестный труд по ООП, в котором данная аксиома хоть как-то используется для обоснования модели ООП и её преимуществ.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, another_coder, Вы писали:

IT>>>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
_>>>Парочка найдется.
G>>Расскажи про них.
_>После вас. Только не забудьте привести архитектуру с коментами почему именно такое решение было принято. Более не вижу смысла продолжать этот тред, т.к. оффтоп.

Да вот у меня как-то не было примеров, чтобы одна и та же программа могла работать с любым источником данных. Скорее обратное. Даже небольшие различия в разных движках БД приводили к различному коду, даже с применением ORM.

Здравствуйте, another_coder, Вы писали:

IT>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
_>Парочка найдется.

А оно там реально было нужно или всё ради понтов?

Здравствуйте, Baudolino, Вы писали:

IT>>Большие дяди в последнее время используют исключительно LINQ.
B>Между нами, большими дядями, LINQ существует только на одной, причем не самой популярной платформе.

Нам, большим дядям пофиг.

Здравствуйте, another_coder, Вы писали:

G>>Расскажи про них.
_>После вас.

Категорически тянет на слив.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, another_coder, Вы писали:

_>>Здравствуйте, gandjustas, Вы писали:

G>>>По-разному это как? Приведи пример.

_>>Ну например, 1 выбирает по одному флагу, 2й выбирает по двум. Система мультитенант, и логика работы определяется динамически. Хранилище у всех IList.
G>Сделать две функции не?

Так можно. Речь тут не о выборе оптимального решения, а о взгляде на роль ропозитория. Не оффтопьте, плиз.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, another_coder, Вы писали:

IT>>>Дружище, скажи сколько ты лично написал систем, в которых неважно что именно есть источник данных (БД, IList, файл или web service)?
_>>Парочка найдется.

IT>А оно там реально было нужно или всё ради понтов?

Было сделано по необходимости. Смысла отвечать глубже нет. Если интересно заведите отдельную тему.

Здравствуйте, another_coder, Вы писали:

_>>>Ну например, 1 выбирает по одному флагу, 2й выбирает по двум. Система мультитенант, и логика работы определяется динамически. Хранилище у всех IList.
G>>Сделать две функции не?
_>Так можно. Речь тут не о выборе оптимального решения, а о взгляде на роль ропозитория. Не оффтопьте, плиз.
Не просто о роли, а о том осмысленно ли его использовать. Ты предлагаешь лепить некоторый паттерн, там где достаточно двух фукнций.
В этом случае паттерн должен обладать явными преимуществами. Расскажи о них.

Здравствуйте, gandjustas, Вы писали:

G>Алан Кей и Бертран Мейер как раз в своих определениях ООП опираются на побочные эффекты при взаимодействии с объектами.

Извините, но резануло глаз. Алане Кей опр. ООП как возможность отправки сообщений объектам -- на это можно, конечно, натянуть побочные эффекты. Мейер в определении ООП вообще побочные эффекты не упоминает.
Мартин или кто-то подобный говорил, что побочные эффекты -- это то, ради чего происходит вычисление.

Здравствуйте, gandjustas.
G>Ты предлагаешь...
Я не предлагаю. Внимательнее перечитай, плиз?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Алан Кей и Бертран Мейер как раз в своих определениях ООП опираются на побочные эффекты при взаимодействии с объектами.

S>Извините, но резануло глаз. Алане Кей опр. ООП как возможность отправки сообщений объектам -- на это можно, конечно, натянуть побочные эффекты. Мейер в определении ООП вообще побочные эффекты не упоминает.

Кей говорил что объекты общаются посредством отправки сообщений.
Мейер прямо говорит, что объекты — данные+методы, а также инкапсуляция+полиморфизм+наследоание.

Какое из этих определений осмысленно, если мы исключаем побочные эффекты от методов или сообщений?


S>Мартин или кто-то подобный говорил, что побочные эффекты -- это то, ради чего происходит вычисление.
Я знаю, что побочные эффекты — то, ради чего происходит вычисление. Но это вовсе не означает, что надо при проектировании опираться на побочные эффекты. На практике как раз проще делать чистые функции, а побочные эффекты изолировать. Но это по ФП, а не ООП.

Здравствуйте, gandjustas, Вы писали:


S>>Извините, но резануло глаз. Алане Кей опр. ООП как возможность отправки сообщений объектам -- на это можно, конечно, натянуть побочные эффекты. Мейер в определении ООП вообще побочные эффекты не упоминает.

G>Кей говорил что объекты общаются посредством отправки сообщений.
G>Мейер прямо говорит, что объекты — данные+методы, а также инкапсуляция+полиморфизм+наследоание.

Не-а, он(Мейер) говорил про абстрактные типы данных, как важнейшую черту ООП. "данные+методы" сильно ниже.

G>Какое из этих определений осмысленно, если мы исключаем побочные эффекты от методов или сообщений?

Справедливое замечание, но вообще-то любое определение осмысленно, поскольку речь идет о другом способе размышлений над побочными эффектами, на другом уровне абстракции. Т.е. они где-то присутствуют (в методах, вестимо), но не это уже главное.

G>опираться на побочные эффекты.

Хорошо звучит, жизнеутверждающе.

Здравствуйте, IT, Вы писали:

IT>>>Потому что в последние лет 8 появились более продвинутые способы работы с БД.
B>>А можно более развернуто? Какие?

IT>Большие дяди в последнее время используют исключительно LINQ.

Дык, а если в базе больше сотни таблиц и несколько сотен хранимок, функций и другого барахла? ИМХО проще чутка подрехтовать интерфейс топикстартера и получить сверхтонкий "репозиторий" поверх линка, тупо для удобства работы.

    interface IRepository<T> where T : class
    {
        ListIQueryable<T> All { get; private set; };
    T Find(int entityId);
        T SaveOrUpdate(T entity);
        T Add(T entity);
        T Update(T entity);
        void Delete(T entity);
    }

В таком случае все эти SP ушли бы в соответствующие репозитории(для совместимости) и их можно было спокойно переделывать в нормальные шарповые функции, оставляя SP только там где реально нужно. Плюс будет место для общей логики.

Здравствуйте, Baudolino, Вы писали:

B>Задача любого архитектурного паттерна — фрагментация сложности.

При условии, что архитектурные решения не вносят ещё больше проблем, чем решают.

B>Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.

Не совсем так. DAL изолирует работу с базой в терминах самой базы от остальной части приложения путём конвертации терминов приложения в термины БД и наоборот.

С этим гораздо лучше справляется LINQ.

Здравствуйте, __SPIRIT__, Вы писали:

IT>>Большие дяди в последнее время используют исключительно LINQ.

__S>Дык, а если в базе больше сотни таблиц и несколько сотен хранимок, функций и другого барахла?

От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс. Что касается сотен всякого барахла, то не вижу никаких проблем. По таблицам генерируется модель данных приложения, которая кстати, может включать и функции и сохранённые процедуры.

Здравствуйте, IT, Вы писали:

IT>>>Большие дяди в последнее время используют исключительно LINQ.

__S>>Дык, а если в базе больше сотни таблиц и несколько сотен хранимок, функций и другого барахла?

IT>От хранимок нужно избавлятся при первом удобном случае.

Так то оно так, но процесс весьма растянут во времени...

IT>Логика в БД — это сегодня нонсенс. Что касается сотен всякого барахла, то не вижу никаких проблем. По таблицам генерируется модель данных приложения, которая кстати, может включать и функции и сохранённые процедуры.

да но если это все запихнуть в один дб контекст, там ничерта не найти будет. Намного удобнее, раскидать их по "репозиториям"

Здравствуйте, __SPIRIT__, Вы писали:

IT>>От хранимок нужно избавлятся при первом удобном случае.
__S>Так то оно так, но процесс весьма растянут во времени...

Именно поэтому рулит linq2db, т.к. совершенно не навязывает своей архитектуры и можно всё начинать использовать в паралель.

__S>да но если это все запихнуть в один дб контекст, там ничерта не найти будет. Намного удобнее, раскидать их по "репозиториям"

Используйте схемы. linq2db для схем генерирует отдельные классы. Например, если таблица Issuer находится в схеме Instrument, то обращение к ней будет

db.Instrument.Issuers

Очень удобно.

Здравствуйте, IT, Вы писали:

IT>Используйте схемы. linq2db для схем генерирует отдельные классы. Например, если таблица Issuer находится в схеме Instrument, то обращение к ней будет

IT>

db.Instrument.Issuers

IT>Очень удобно.

в принципе вариант.

Здравствуйте, IT.

Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще? При этом я хочу менять способ доступа к данным, оставляя все остальное.

Здравствуйте, Baudolino.

Я еще гляну на этот большой ответ. Но вот тут интересный вопрос у меня возник по той же теме. Можешь, плиз, глянуть? Интересно твое мнение здесь

Автор: another_coder
Дата: 22.06.16

Здравствуйте, another_coder, Вы писали:

_>Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще?

Я бы такую штуку назвал помойкой.

Здравствуйте, IT, Вы писали:

IT>Я бы такую штуку назвал помойкой.

Тем не менее, она есть в каждом проекте. Опишите, как вы все это объединяете в одном проекте? Если у вас был опыт, конечно.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, IT.

_>Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще? При этом я хочу менять способ доступа к данным, оставляя все остальное.

Не знаю как у тебя, а у меня эти функции выполняет Entity Framework. Он умеет логировать запросы, сохраняет в памяти запрошенные объекты и собственно получает данные.

Ты все-таки потрудись привести сценарий, когда и чего нужно менять в доступе к данным и какие для этого абстракции ты создашь. Иначе получается сферический конь.

Здравствуйте, another_coder, Вы писали:

_>Тем не менее, она есть в каждом проекте. Опишите, как вы все это объединяете в одном проекте? Если у вас был опыт, конечно.

Опыт если когда-то и был, то я уже не помню.

Здравствуйте, gandjustas.

G>Не знаю как у тебя, а у меня эти функции выполняет Entity Framework. Он умеет логировать запросы, сохраняет в памяти запрошенные объекты и собственно получает данные.

G>Ты все-таки потрудись привести сценарий, когда и чего нужно менять в доступе к данным и какие для этого абстракции ты создашь. Иначе получается сферический конь.

Это хорошо, но если так получилось что проект писали те, кто не знает, как EF все это делает, или когда его еще не было, то, вполне возможно, они захотят ручками это все реализовать. Например, старинный проект, где все было написано на ADO.NET, а теперь решили переехать на EF. Сразу все переписать — нереально. Получается поэтапный переезд с выделением одного, другого. Появляется сначала, как бы, два репозитория, которые выполняют разные вещи:

1) реализует всю кухню по созданию бизнесс объектов (начальные условия выборок, системные фильтры, если нет в хранимках и пр)
2) реализует сам доступ к данным с помощью либо ADO.NET, либо EF.

Тут получается неоднозначная ситуация: два объекта, с разным назначением, описываются одним и тем же термином, по классическому определению: оба оперируют списками объектов. Но по факту у объектов разные цели.

Получилось мне описать ситуацию, чтобы она не была похожа на коня в вакууме?
Ну вот еще один пример о том же, но с другой стороны. Например, делался стартап. DAL написали по фаулеру, создали репозиторий, как в самом начале. С ростом проекта решили, что надо поддерживать разные базы (классика!), но BLL и DAL то уже написаны и это не переписать за неделю. <долгий рассказ о детялх>. Поэтому выделили в DAL провайдер данных из репозитория. По сути выделили один объект из другого, у которых практически идентичный CRUD интерфейс. Только прошлый стал как бы более умным и его дергают объекты BLL, а он дергает новый "репозиторий". И тут снова ситуация, когда новый человек в проекте может спросить: "нафига вам два репозитория? что за булшит?"
Можно предположить, что второй объект это не репозиторий, а DAO. А вот первый — репозиторий. Если так, то до момента изменения архитектуры никакого репозитория не было. Иначе, получается, что термин репозиторий сначала обозначал одно, потом другое. Собственно, этот момент мне и не нравится. Я считаю, что термин должен однозначно описывать то, что за ним скрывается. Например, при старте проекта так и называть: мы создаем DAO. Тогда акценты сразу правильно будут расставляться и говны в коде будет поменьше. Ведь никто не захочет в DAO запихивать еще и джойны и пр, как мне кажется.

Как у вас получается различать объекты в похожей ситуации?

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, gandjustas.

G>>Не знаю как у тебя, а у меня эти функции выполняет Entity Framework. Он умеет логировать запросы, сохраняет в памяти запрошенные объекты и собственно получает данные.

G>>Ты все-таки потрудись привести сценарий, когда и чего нужно менять в доступе к данным и какие для этого абстракции ты создашь. Иначе получается сферический конь.

_>Это хорошо, но если так получилось что проект писали те, кто не знает, как EF все это делает, или когда его еще не было, то, вполне возможно, они захотят ручками это все реализовать.
Я писал проект на делфи в 2005 году и делал свой orm, у меня там было и логирование запросов и identity map для кеша объектов. Там был реализован паттерн repository точно как описал фаулер. Но ни одного класса с таким именем не было.

Сегодня вообще нет необходимости писать полностью доступ к данным, а не использовать ef\linq2db\hibernate.


_>Например, старинный проект, где все было написано на ADO.NET, а теперь решили переехать на EF. Сразу все переписать — нереально. Получается поэтапный переезд с выделением одного, другого. Появляется сначала, как бы, два репозитория, которые выполняют разные вещи:
А с чего ты взял что репозитарий там был? Мания везде тулить репозитарии появилась относительно недавно. И уже сильно после того, как появились ORM.
Но даже если предположить, что бы, то зачем делать два — неясно совершенно.
1) Для начала надо заменить ручной маппинг и DbCommand на linq2db
2) Потом текстовые запросы\хранимки переписать на Linq
3) Потом прокинуть IQueryable выше по стеку вызовов и сократить количество методов в dal
Если что — я уже так делал на одном проекте.

_>Тут получается неоднозначная ситуация: два объекта, с разным назначением, описываются одним и тем же термином, по классическому определению: оба оперируют списками объектов. Но по факту у объектов разные цели.
Никаких двух не будет.

Я уже понял что наличие repository обосновывается только желанием делать repository. Никаких объективных причин пилить их нету.

_>Получилось мне описать ситуацию, чтобы она не была похожа на коня в вакууме?
Пока нет.

Так и не увидел необходимости иметь два разных метода доступа к одним и тем же данным. Так и не увидел потребности вручную реализовывать паттерн repository.


_>Ну вот еще один пример о том же, но с другой стороны. Например, делался стартап. DAL написали по фаулеру, создали репозиторий, как в самом начале. С ростом проекта решили, что надо поддерживать разные базы (классика!), но BLL и DAL то уже написаны и это не переписать за неделю. <долгий рассказ о детялх>. Поэтому выделили в DAL провайдер данных из репозитория. По сути выделили один объект из другого, у которых практически идентичный CRUD интерфейс. Только прошлый стал как бы более умным и его дергают объекты BLL, а он дергает новый "репозиторий". И тут снова ситуация, когда новый человек в проекте может спросить: "нафига вам два репозитория? что за булшит?"
Процитирую себя

Я уже понял что наличие repository обосновывается только желанием делать repository. Никаких объективных причин пилить их нету.

_>Как у вас получается различать объекты в похожей ситуации?
Никак, я сотру нафиг это говно. код доступа к данным, у которого в баз 10 табличек (стартап же) переписывается на ORM за полдня.

Здравствуйте, another_coder, Вы писали:

_>Здравствуйте, IT.

_>Вопрос относительно терминологии. Как вы назовете объект, который будет связывать в единую конфигурацию такие вещи, как кеш, аудит доступка к данным, сам доступ к данным и что-нибудь еще? При этом я хочу менять способ доступа к данным, оставляя все остальное.
Связыванием занимается обычно контейнер DI, на основе конфигурации. Конкретные задачи кэширования и аудита можно решать декларативно через AOP, тогда у вас реализация доступа к данным от них зависеть не будет, и ее будет проще изменить. Пример изменения: почитав восторженные отзывы технохипстеров, попробовали какую-нибудь MongoDB, не понравилось, переехали в старый добрый Postgres. Меняется только конфигурация DI и реализация работы с хранилищем в DAO (ODM -> ORM). DI как навешивал, используя паттерн Proxy, журналирование и кэширование результатов вызовов методов DAO, так и навешивает — ему пофиг, что там внутри. Потом, конечно, надо будет посмотреть, как система ведёт себя в разных профилях нагрузки, но там доработки будут точечными.

Здравствуйте, IT, Вы писали:

IT>У нас класс так называется только потому что как-то не придумалось другого названия. Но с предложенным интерфейсом репозитория он не имеет ничего общего. Во-первых, у нас вообще нет никакого интерфейса, потому что он нафиг не нужен. Во-вторых, основная задача нашего класса — возможность тестирования процессов, которые его используют без чтения данных из базы. Т.е. это ближе к DI, чем к паттерну Repository. А здесь репозиторий нужен как часть или даже замена DAO, такой классический пережиток тяжелого прошлого.

А не могли бы вы приблизительную сигнатуру вашего класса показать? Так чтобы точно понимать...

Здравствуйте, IT, Вы писали:

IT>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, IT, Вы писали:

IT>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
G>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.
А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

Здравствуйте, gandjustas, Вы писали:

G>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.
G>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

Привести пример это целое дело. Попробую кратко.
ORM — NHibernate. Есть таблица узлов, они по дискриминатору разделены на два класса. Между узлами есть связи, что хранятся в отдельной таблице. Я выбираю такие связи у которых с одной стороны узел определенного типа, а также узлы с определенным свойством. У ORM получается 4 join, хотя можно было бы обойтись 2-мя с and в условии. Пришлось изголятся и использовать устаревший синтаксис. Там получилось нормальное количество join, но при этом вытягиваются данные не только по связям, но и по узлам... Вот такая альтернатива.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, gandjustas, Вы писали:

G>>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.
G>>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

G>Привести пример это целое дело. Попробую кратко.
G>ORM — NHibernate. Есть таблица узлов, они по дискриминатору разделены на два класса. Между узлами есть связи, что хранятся в отдельной таблице. Я выбираю такие связи у которых с одной стороны узел определенного типа, а также узлы с определенным свойством. У ORM получается 4 join, хотя можно было бы обойтись 2-мя с and в условии. Пришлось изголятся и использовать устаревший синтаксис. Там получилось нормальное количество join, но при этом вытягиваются данные не только по связям, но и по узлам... Вот такая альтернатива.

Приведите код, так не понятно о чем речь. Скорее всего вы слишком много игрались моделированием в NHibernate, поэтому такой результат.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Gattaka, Вы писали:

G>>Здравствуйте, IT, Вы писали:

IT>>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
G>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.

G>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

По-моему наоборт -- на sql можно четко сформулировать запрос без всяческих подпрыжек, вот с linq недавно огрбеб -- http://docs.telerik.com/data-access/developers-guide/profiling-and-tuning/profiler-and-tuning-advisor/data-access-profiler-n-plus-one-problem

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Gattaka, Вы писали:

G>>>Здравствуйте, IT, Вы писали:

IT>>>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
G>>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.

G>>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

S>По-моему наоборт -- на sql можно четко сформулировать запрос без всяческих подпрыжек
Нельзя, если запрос параметризованный.

типичный случай для приложения — отображение списка с фильтрами — 3 фильтра+постраничная разбивка. Фильтры по умолчанию не фильтруют ничего и могут быть выбраны в любой комбинации. Linq сгенерирует 8 или 16 разных запросов для различных сочетаний фильтров и страниц.
На SQL будет написан один запрос с тремя условиями примерно такого вида:

where 1=1
and (t.Field1 = @p1 or @p1 is null)
and (t.Field2 = @p2 or @p2 is null)
and (t.Field3 = @p3 or @p3 is null)

План запроса в этом случае будет далек от оптимального и подвержен parameter sniffing problem.

Тут подробно http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/

В реальности еще добавится сортировка и разные проекции в запросах с одинаковыми предикатами. Общее количество возможных запросов перевалит за 50. При этом такой запрос будет на главной странице и должен работать максимально быстро. Linq тут очень поможет, а в SQL это будет АД.

S>вот с linq недавно огрбеб -- http://docs.telerik.com/data-access/developers-guide/profiling-and-tuning/profiler-and-tuning-advisor/data-access-profiler-n-plus-one-problem
lazy load надо отключать всегда и лучше не пользоваться ORM где он включен. В EF он отключен по-умолчанию для code-first, а в linq2db его вовсе нет.

Здравствуйте, Gattaka, Вы писали:

IT>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
G>Красивый сказка, которая не выдерживает проверку практикой.

Не знаю какая у тебя практика, а я последние 10 лет занимаюсь в осном изничтожением сохранённых процедур в стиле инквизиции. Увидел, поймал, сразу на костёр.

G>При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.

Это вы, батенька, готовить не умеете. Выкинь все свои ORM на помойку и возьми ту, которая генерирует только то, что ей сказано.

Здравствуйте, Gattaka, Вы писали:

G>А не могли бы вы приблизительную сигнатуру вашего класса показать? Так чтобы точно понимать...

Не мог бы. Там и сигнатуры особенной нет. Это просто класс без всяких интерфейсов и паттернов, в котором куча коллекций с данными. Методы для инициализации и ещё какой-то фигни по мелочи. Просто большой контейнер. Это его основная задача.

Здравствуйте, gandjustas, Вы писали:



G>типичный случай для приложения — отображение списка с фильтрами — 3 фильтра+постраничная разбивка. Фильтры по умолчанию не фильтруют ничего и могут быть выбраны в любой комбинации. Linq сгенерирует 8 или 16 разных запросов для различных сочетаний фильтров и страниц.
G>На SQL будет написан один запрос с тремя условиями примерно такого вида:
G>

G>where 1=1
G>and (t.Field1 = @p1 or @p1 is null)
G>and (t.Field2 = @p2 or @p2 is null)
G>and (t.Field3 = @p3 or @p3 is null)
G>

G>План запроса в этом случае будет далек от оптимального и подвержен parameter sniffing problem.

G>Тут подробно http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/

G>В реальности еще добавится сортировка и разные проекции в запросах с одинаковыми предикатами. Общее количество возможных запросов перевалит за 50. При этом такой запрос будет на главной странице и должен работать максимально быстро. Linq тут очень поможет, а в SQL это будет АД.

Не верю. Во-первых, надо смотреть на план linq запросов, которых аж целых 8 вместо 1. Во-вторых, спорно ибо нормальный спец. в рбд. напишет может написать запрос явно не хуже чем чем linq сгенеренный.


S>>вот с linq недавно огрбеб -- http://docs.telerik.com/data-access/developers-guide/profiling-and-tuning/profiler-and-tuning-advisor/data-access-profiler-n-plus-one-problem
G>lazy load надо отключать всегда и лучше не пользоваться ORM где он включен. В EF он отключен по-умолчанию для code-first, а в linq2db его вовсе нет.

да-да-да, и сразу подгружать всю базу данных со всеми join'ами, которые не нужны.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:



G>>типичный случай для приложения — отображение списка с фильтрами — 3 фильтра+постраничная разбивка. Фильтры по умолчанию не фильтруют ничего и могут быть выбраны в любой комбинации. Linq сгенерирует 8 или 16 разных запросов для различных сочетаний фильтров и страниц.

S>Не верю.
Можешь проверить


S>Во-первых, надо смотреть на план linq запросов, которых аж целых 8 вместо 1.
Тогда идея с рукопашными запросами покажется совсем глупой. Потому что у каждого запроса из 8 будет свой оптимальный план.
А рукопашный запрос вида

where 1=1
and (t.Field1 = @p1 or @p1 is null)
and (t.Field2 = @p2 or @p2 is null)
and (t.Field3 = @p3 or @p3 is null)

Будет иметь план, который оптимален только для одного из 8 сочетаний параметров. Чем больше параметров тем хуже, никакие индексы не помогут. Поможет только option (recompile), но добавит затраты на компиляцию запроса каждый раз.

Погугли советы использовать option (recompile), почти везде вместо него можно использовать генератор запросов.


S>Во-вторых, спорно ибо нормальный спец. в рбд. напишет может написать запрос явно не хуже чем чем linq сгенеренный.
Нормальный спец напишет запрос явно не хуже, чем linq. ОДИН запрос.
Поддерживать самописный генератор или несколько десятков однотипных запросов даже "нормальный спец" не сможет.


S>>>вот с linq недавно огрбеб -- http://docs.telerik.com/data-access/developers-guide/profiling-and-tuning/profiler-and-tuning-advisor/data-access-profiler-n-plus-one-problem
G>>lazy load надо отключать всегда и лучше не пользоваться ORM где он включен. В EF он отключен по-умолчанию для code-first, а в linq2db его вовсе нет.
S>да-да-да, и сразу подгружать всю базу данных со всеми join'ами, которые не нужны.
Ты о чем сейчас?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Sharov, Вы писали:

S>>Здравствуйте, gandjustas, Вы писали:



G>>>типичный случай для приложения — отображение списка с фильтрами — 3 фильтра+постраничная разбивка. Фильтры по умолчанию не фильтруют ничего и могут быть выбраны в любой комбинации. Linq сгенерирует 8 или 16 разных запросов для различных сочетаний фильтров и страниц.

S>>Не верю.
G>Можешь проверить


S>>Во-первых, надо смотреть на план linq запросов, которых аж целых 8 вместо 1.
G>Тогда идея с рукопашными запросами покажется совсем глупой. Потому что у каждого запроса из 8 будет свой оптимальный план.
G>А рукопашный запрос вида
G>

G>where 1=1
G>and (t.Field1 = @p1 or @p1 is null)
G>and (t.Field2 = @p2 or @p2 is null)
G>and (t.Field3 = @p3 or @p3 is null)
G>

G>Будет иметь план, который оптимален только для одного из 8 сочетаний параметров. Чем больше параметров тем хуже, никакие индексы не помогут. Поможет только option (recompile), но добавит затраты на компиляцию запроса каждый раз.

G>Погугли советы использовать option (recompile), почти везде вместо него можно использовать генератор запросов.

А linq то как поможет?

S>>Во-вторых, спорно ибо нормальный спец. в рбд. напишет может написать запрос явно не хуже чем чем linq сгенеренный.
G>Нормальный спец напишет запрос явно не хуже, чем linq. ОДИН запрос.
G>Поддерживать самописный генератор или несколько десятков однотипных запросов даже "нормальный спец" не сможет.

Вы смеетесь ??? Т.е. если Вы возьмете человека на фул-тайм с задачей написания sql запросов (специалиста), он больше одного запроса написать не сможет? Не считая того, что вообще говоря это должно быть компетенцией разработчика, отв. за соотв. таблицы (сущности).

S>>>>вот с linq недавно огрбеб -- http://docs.telerik.com/data-access/developers-guide/profiling-and-tuning/profiler-and-tuning-advisor/data-access-profiler-n-plus-one-problem
G>>>lazy load надо отключать всегда и лучше не пользоваться ORM где он включен. В EF он отключен по-умолчанию для code-first, а в linq2db его вовсе нет.
S>>да-да-да, и сразу подгружать всю базу данных со всеми join'ами, которые не нужны.
G>Ты о чем сейчас?

Ну как-бы у openaccess telerik'овского допустим есть eager loading и laze loading (как и везде). При подгрузке родительских сущностей все дочерние сущности соотв родительской тоже подгрузятся, даже если они не нужны.

Здравствуйте, gandjustas, Вы писали:

S>>Во-первых, надо смотреть на план linq запросов, которых аж целых 8 вместо 1.
G>Тогда идея с рукопашными запросами покажется совсем глупой. Потому что у каждого запроса из 8 будет свой оптимальный план.
G>А рукопашный запрос вида
G>

G>where 1=1
G>and (t.Field1 = @p1 or @p1 is null)
G>and (t.Field2 = @p2 or @p2 is null)
G>and (t.Field3 = @p3 or @p3 is null)
G>

G>Будет иметь план, который оптимален только для одного из 8 сочетаний параметров. Чем больше параметров тем хуже, никакие индексы не помогут. Поможет только option (recompile), но добавит затраты на компиляцию запроса каждый раз.

G>Погугли советы использовать option (recompile), почти везде вместо него можно использовать генератор запросов.
Во первых это не такие уж большие затраты, потом еще не известно что более затратно перекомпилировать один запрос. Или хранить N-атцать планов запросов и тоже их перекомпилировать при обновлении статистики, например.
И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
По кейсу что вы описали: На SQL вы можете разбить запрос на 2 подзапроса, например с помощью табличных выражений. Можете добавить view, затем ее проиндексировать. Все зависит от конкретной системы и т.п. Точно так же никто не отменял динамический sql sp_exec... Вы можете сформировать строчку запроса, а потом ее выполнить. Прямо как linq.

Здравствуйте, IT, Вы писали:

B>>Задача любого архитектурного паттерна — фрагментация сложности.
IT>При условии, что архитектурные решения не вносят ещё больше проблем, чем решают.
Разумеется.

B>>Паттерны DAL отделяют сложность бизнес-логики от сложности работы с хранилищем данных с помощью разного вида интерфейсов.
IT>Не совсем так. DAL изолирует работу с базой в терминах самой базы от остальной части приложения путём конвертации терминов приложения в термины БД и наоборот.
Ну в общем, да. Можно еще короче сказать: абстрагируют работу с хранилищем, причем не обязательно БД: например, вы обрабатываете какие-то документы и изначально храните их в блобах в БД, потом переносите в облачное хранилище типа Amazon S3 — если оптимизация за счет отдачи прямых ссылок на хранилище невозможна (например, потому что клиент в интернете, а хранилище в VPN) или не требуется (например, потому что клиенту нужны результаты обработки, а не сами документы), то интерфейс DAL и бизнес-логику можно при этом не менять.

Здравствуйте, Sharov, Вы писали:

G>>А рукопашный запрос вида
G>>

G>>where 1=1
G>>and (t.Field1 = @p1 or @p1 is null)
G>>and (t.Field2 = @p2 or @p2 is null)
G>>and (t.Field3 = @p3 or @p3 is null)
G>>

G>>Будет иметь план, который оптимален только для одного из 8 сочетаний параметров. Чем больше параметров тем хуже, никакие индексы не помогут. Поможет только option (recompile), но добавит затраты на компиляцию запроса каждый раз.

S>А linq то как поможет?

C linq будет написан такой код:

if(p1 != null) q = q.Where(t => t.Field1 = p1);
if(p2 != null) q = q.Where(t => t.Field2 = p2);
if(p3 != null) q = q.Where(t => t.Field3 = p3);

В итоге в зависимости от параметров будет 8 запросов, каждый с оптимальным планом под свое сочетание параметров. Каждый из 8 запросов может быть оптимизирован своим индексом.


S>Вы смеетесь ??? Т.е. если Вы возьмете человека на фул-тайм с задачей написания sql запросов (специалиста), он больше одного запроса написать не сможет? Не считая того, что вообще говоря это должно быть компетенцией разработчика, отв. за соотв. таблицы (сущности).
Конечно сможет. И два сможет, и десять и может даже 50. Для статистики — у меня в очень простом приложении с 5 таблицами в базе получилось суммарно 60 разных запросов. А нанимать спеца отдельно по БД для базы менее чем два десятка таблиц никто не будет. Вот и посчитай какое количество запросов ему надо будет поддерживать.


S>Ну как-бы у openaccess telerik'овского допустим есть eager loading и laze loading (как и везде). При подгрузке родительских сущностей все дочерние сущности соотв родительской тоже подгрузятся, даже если они не нужны.
Выкини это говно и возьми linq2db или ef. Они грузят ровно то, что скажешь.

Здравствуйте, Gattaka, Вы писали:

G>>Погугли советы использовать option (recompile), почти везде вместо него можно использовать генератор запросов.
G>Во первых это не такие уж большие затраты, потом еще не известно что более затратно перекомпилировать один запрос. Или хранить N-атцать планов запросов и тоже их перекомпилировать при обновлении статистики, например.
Конечно перекомпиляция на каждый вызов более затрата если вызовов больше чем N, где N — количество запросов сгенерированных linq. N обычно не превышает 15. То есть если у тебя запрос вызывается 15 и более раз, то выгоднее использовать linq (или другой генератор), а не option recompile. Хранение планов не стоит ничего, потому что планов всегда ограниченное количество и надо сервак подобрать, чтобы plan cache не вытеснялся.

G>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.

G>По кейсу что вы описали: На SQL вы можете разбить запрос на 2 подзапроса, например с помощью табличных выражений.
Все равно план запроса будет один, со всеми вытекающими.

G>Можете добавить view, затем ее проиндексировать.
Индексированные view точно также можно и в linq использовать.

G>Все зависит от конкретной системы и т.п. Точно так же никто не отменял динамический sql sp_exec... Вы можете сформировать строчку запроса, а потом ее выполнить. Прямо как linq.
Да-да, давайте клеить строки руками, а не пользоваться гарантиями компилятора.
Опытный разработчик sql склейку строк делает один раз, а потом не связывается с такой архитектурой.

Здравствуйте, gandjustas, Вы писали:

G>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
G>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.
Выгоднее это да, но насколько? План запроса компилируется пару милисекунд, можно для каждого конкретного посмотреть в плане. И на чем мы экономим? Если сам запрос выполняется пару секунд. Ну... если хорошо скомпилировался. Если плохо — полчаса. Здесь баланс нужно соблюдать. На самом деле что ORM хорошо делает, это простейший CRUD, самый простейший. И сценарий что вы описали. Но это по факту Read.

G>>По кейсу что вы описали: На SQL вы можете разбить запрос на 2 подзапроса, например с помощью табличных выражений.
G>Все равно план запроса будет один, со всеми вытекающими.

G>>Можете добавить view, затем ее проиндексировать.
G>Индексированные view точно также можно и в linq использовать.
Ну и что это за уровень абстракции в таком случае? Это всего лишь способ писать SQL на C#. Извращение...

Здравствуйте, another_coder, Вы писали:

_>Удивляют люди, которые считают, что правильный репозиторий должен выголядить как этот интерфейс
Я сам был таким и писал такой код, однако через некоторое время он переставал писаться и всё становилось очень криво. Когда код пишется с трудом, для меня это знак что что-то я делаю не так.
_>Это ни что иное, как реализация DAO паттерна. Сам же репозиторий может совершенно не знать о механике и деталях хранения данных (база, файлы, сервис). На маленьких проектах разницу не так сильно видно. А на больших, когда помимо самих запросов, еще необходимо прикрутить кеширование, логирование, фильтрацию по служебным полям, вдруг оказывается, что репозиторий уже совсем не то же, что DAO.
_>Отсюда и вопросы у новичков, типа, должен ли репозиторий иметь методы GetSomethingByUser, GetUserTickets или просто CRUD не зная про другие репозитории и типы.
Это шлюз таблицы, а не репозиторий. http://martinfowler.com/eaaCatalog/tableDataGateway.html

_>А современные фреймворки еще сильнее путают разрабов, реализуя весь Data Access слой. И те, что DAO называли репозиториями начинают думать, что репозитории не нужны, и можно Linq-кодом прошить всю бизнес логику. Даже картинки у Фаулера и на MSDN способствуют тому, что репозиторий воспринимается, главным образом, как провайдер данных, т.е. абстракция над RDBMS, хотя его роль более значимая при проектировании. Возможно, я начитался DDD книжек.
Фаулер отличает репозиторий и шлюз таблицы — у него это разные концепции. Проблема примеров — им надо показать всё и сразу, поэтому они очень сильно упрощают код. Код из примеров нельзя воспринимать как руководство к действию.

_>Не кажется ли вам, что пора идею репозитория несколько подправить, чтобы когда один говорил другому этот термин, то оба понимали что-то одно?
Репозиторий — это просто коллекция объектов из предметной области. Когда люди заводят речь о репозиториях, они имеют в виду совсем другое — как объекты предметной области будут существовать между запусками программы. Абсолютно две разных проблемы — управление множеством объектов и управление жизнью объектов. Надо задавать наводящие вопросы и уточнять термины.

Здравствуйте, Sinix, Вы писали:

S>Кэп: код здорового человека выглядит примерно так:
S>

S>[Transactional]
S>void SetRecordData(string code, string data)
S>{
S>  var existing = Context.FirstOrDefault<MyRecord>(r => r.Code == code);
S>  if (data == null)
S>  {
S>    existing?.Delete();
S>  }
S>  else
S>  {
S>    if (existing == null)
S>    {
S>       existing = Context.NewObject<MyRecord>(r => r.Code = code);
S>    }

S>    existing.Data = data;
S>  }  
S>}
S>

S>Т.е. ноль технических деталей, вся магия под капотом.

Вся магия наружу, эти два вызова подряд сделают две разных операции. Один вызов удалит запись, другой создаст, или наоборот.

SetRecordData("abc", null);
SetRecordData("abc", null);

Даже непонятно, что оно вообще делать должно. Upsert?

Здравствуйте, Vladek, Вы писали:
V>Вся магия наружу, эти два вызова подряд сделают две разных операции. Один вызов удалит запись, другой создаст, или наоборот.

Эй, это как бы профильный форум Тут ответы можно читать, а не пропускать и сразу переходить к "а вот почему ты неправ"

1. С кодом всё ок. Хинт: if (data == null) ... else ...

2.

Разумеется, код сферический в вакууме, просто чтоб показать основные сценарии.

Вопросы?

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, gandjustas, Вы писали:

G>>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
G>>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.
G>Выгоднее это да, но насколько? План запроса компилируется пару милисекунд, можно для каждого конкретного посмотреть в плане. И на чем мы экономим? Если сам запрос выполняется пару секунд. Ну... если хорошо скомпилировался. Если плохо — полчаса. Здесь баланс нужно соблюдать. На самом деле что ORM хорошо делает, это простейший CRUD, самый простейший. И сценарий что вы описали. Но это по факту Read.
Баланс чего? Тут нет tradeoff, запросы, сгенерированные Linq не требуют перекомпиляции, а рукопашные требуют.

G>Ну и что это за уровень абстракции в таком случае? Это всего лишь способ писать SQL на C#. Извращение...
Ну и пусть извращение, какая разница? Я готов заниматься любыми извращениями если сокращает затраты.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Gattaka, Вы писали:

G>>Здравствуйте, gandjustas, Вы писали:

G>>>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
G>>>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.
G>>Выгоднее это да, но насколько? План запроса компилируется пару милисекунд, можно для каждого конкретного посмотреть в плане. И на чем мы экономим? Если сам запрос выполняется пару секунд. Ну... если хорошо скомпилировался. Если плохо — полчаса. Здесь баланс нужно соблюдать. На самом деле что ORM хорошо делает, это простейший CRUD, самый простейший. И сценарий что вы описали. Но это по факту Read.
G>Баланс чего? Тут нет tradeoff, запросы, сгенерированные Linq не требуют перекомпиляции, а рукопашные требуют.

G>>Ну и что это за уровень абстракции в таком случае? Это всего лишь способ писать SQL на C#. Извращение...
G>Ну и пусть извращение, какая разница? Я готов заниматься любыми извращениями если сокращает затраты.


Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы.
Я уже описывал что за проблемы — при работе с дискриминаторами в 2 раза больше джойнов вместо условий в самих джойнах. И что тогда будет толку от кучи конкретных запросов, которые не перекомпилируются, но содержат лишние джойны?
Если посмотреть на EF там постоянно запросы вида select ... from (select ... запрос...) — почему-то селект из селекта, очень странно.
Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.

Здравствуйте, Gattaka, Вы писали:


G>Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы.
Типичное веб-приложение а 98% состоит из выборок, а их удобнее делать в генераторе запросов типа linq, а не в ХП.

G>Я уже описывал что за проблемы — при работе с дискриминаторами в 2 раза больше джойнов вместо условий в самих джойнах. И что тогда будет толку от кучи конкретных запросов, которые не перекомпилируются, но содержат лишние джойны?
Это проблема конкретно NHibernate и модели, а не ORM в принципе. Выбирай нормальные средства.

G>Если посмотреть на EF там постоянно запросы вида select ... from (select ... запрос...) — почему-то селект из селекта, очень странно.
derived table прекрасно оптимизируются, смотри планы запросов.

G>Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.
хз. а на что вообще это влияет?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Gattaka, Вы писали:


G>>Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы.
G>Типичное веб-приложение а 98% состоит из выборок, а их удобнее делать в генераторе запросов типа linq, а не в ХП.
Ну тифичное веб-приложение это да.

G>>Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.
G>хз. а на что вообще это влияет?
Ну вобщето при обновлении лучше обновлять только то, что вы изменили. Как и с выборкой. Как стреляет. Положим вы в приложении обновляете какое-то свойство, но обнаруживаете что это происходит как-то медленно. Капаете и обнаруживаете, что NH обновляет все свойства, в том числе которое фигурирует в индексированной вьюшке и развернуто на 100500 строчек в этой вьюшке. Теперь SQL Server нужно пройтись записям этой вьюшки и везде заменить то же самое значение на то же самой. Как-то так...

Здравствуйте, Gattaka, Вы писали:

G>>>Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.
G>>хз. а на что вообще это влияет?
G>Ну вобщето при обновлении лучше обновлять только то, что вы изменили.
Кому лучше? Ты хоть представляешь как работает обновление на уровне страниц?

G>Как и с выборкой.
Не как с выборкой

G>Положим вы в приложении обновляете какое-то свойство, но обнаруживаете что это происходит как-то медленно. Капаете и обнаруживаете, что NH обновляет все свойства, в том числе которое фигурирует в индексированной вьюшке и развернуто на 100500 строчек в этой вьюшке. Теперь SQL Server нужно пройтись записям этой вьюшки и везде заменить то же самое значение на то же самой. Как-то так...
Уверен, что отсутствие поля в update не вызывает пересчет вьюшки? Я что-то очень сомневаюсь.

Здравствуйте, gandjustas, Вы писали:

G>>Ну вобщето при обновлении лучше обновлять только то, что вы изменили.
G>Кому лучше? Ты хоть представляешь как работает обновление на уровне страниц?
Ну хотябы потому что трафик за счет самого запроса больше. Там ведь у сущности могут быть и с мегатекстом и бинарной гадостью всякой. Да даже если просто поля... В любом случае лучше меньше трафика. Насчет апдейта на самом сервере я соглашусь что в большенстве случаев это почти то же самое. Но если у вас фрагментация страниц большая или есть расщипленные страницы? Вобщем ИМХО очевидно, что лучше минимизировать объем обнавления данных — это хороший стиль. Как зубы чистить. С какого бабуя я должен то же самое на то же самое перетирать? Только из-за того что у разработчиков ОРМ — лениво писать грамотный код.

G>>Как и с выборкой.
G>Не как с выборкой

G>>Положим вы в приложении обновляете какое-то свойство, но обнаруживаете что это происходит как-то медленно. Капаете и обнаруживаете, что NH обновляет все свойства, в том числе которое фигурирует в индексированной вьюшке и развернуто на 100500 строчек в этой вьюшке. Теперь SQL Server нужно пройтись записям этой вьюшки и везде заменить то же самое значение на то же самой. Как-то так...
G>Уверен, что отсутствие поля в update не вызывает пересчет вьюшки? Я что-то очень сомневаюсь.
Проверяли. А что оно будет обновлятс? Поле, которое фигурирует в вьюшке не меняется. А в случае с перезаписью то же самое на то же самое — формально меняется...

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, gandjustas, Вы писали:

G>Только из-за того что у разработчиков ОРМ — лениво писать грамотный код.
Это у разработчиков NHibernate, в EF проверил — в Update уходят только обновленные поля. В linq2db уверен то же самое.

Здравствуйте, Baudolino, Вы писали:

IT>>Не совсем так. DAL изолирует работу с базой в терминах самой базы от остальной части приложения путём конвертации терминов приложения в термины БД и наоборот.
B>Ну в общем, да. Можно еще короче сказать: абстрагируют работу с хранилищем, причем не обязательно БД:

Нет. Основная функция DAL — изоляция работы с БД от остальной части приложения. То, что это обладает ещё какими-то другими свойствами — это побочный эффект. Например, ту же обстракцию БД вполне хорошо, даже лучше чем DAL выполняет LINQ, но принципиально по-другому.

Здравствуйте, gandjustas, Вы писали:

G>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
G>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.

https://github.com/linq2db/linq2db/blob/master/Tests/Linq/Linq/QueryHintsTests.cs#L63

Здравствуйте, gandjustas, Вы писали:

G>Это у разработчиков NHibernate, в EF проверил — в Update уходят только обновленные поля. В linq2db уверен то же самое.

В linq2db вообще нет такого. Вместо этого linq2db поддерживат DML и DDL.

Здравствуйте, Vladek, Вы писали:


_>>А современные фреймворки еще сильнее путают разрабов, реализуя весь Data Access слой. И те, что DAO называли репозиториями начинают думать, что репозитории не нужны, и можно Linq-кодом прошить всю бизнес логику. Даже картинки у Фаулера и на MSDN способствуют тому, что репозиторий воспринимается, главным образом, как провайдер данных, т.е. абстракция над RDBMS, хотя его роль более значимая при проектировании. Возможно, я начитался DDD книжек.
V>Фаулер отличает репозиторий и шлюз таблицы — у него это разные концепции. Проблема примеров — им надо показать всё и сразу, поэтому они очень сильно упрощают код. Код из примеров нельзя воспринимать как руководство к действию.

Какой смысл лепить отдельный паттерн "шлюз таблицы" Идиотизм. Это тоже самое, что и репозиторий, только конкретно типизированный под бд. Т.е. это одна и та же концепция.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Gattaka, Вы писали:

G>>А не могли бы вы приблизительную сигнатуру вашего класса показать? Так чтобы точно понимать...

IT>Не мог бы. Там и сигнатуры особенной нет. Это просто класс без всяких интерфейсов и паттернов, в котором куча коллекций с данными. Методы для инициализации и ещё какой-то фигни по мелочи. Просто большой контейнер. Это его основная задача.

God-object )

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, Vladek, Вы писали:


_>>>А современные фреймворки еще сильнее путают разрабов, реализуя весь Data Access слой. И те, что DAO называли репозиториями начинают думать, что репозитории не нужны, и можно Linq-кодом прошить всю бизнес логику. Даже картинки у Фаулера и на MSDN способствуют тому, что репозиторий воспринимается, главным образом, как провайдер данных, т.е. абстракция над RDBMS, хотя его роль более значимая при проектировании. Возможно, я начитался DDD книжек.
V>>Фаулер отличает репозиторий и шлюз таблицы — у него это разные концепции. Проблема примеров — им надо показать всё и сразу, поэтому они очень сильно упрощают код. Код из примеров нельзя воспринимать как руководство к действию.

S>Какой смысл лепить отдельный паттерн "шлюз таблицы" Идиотизм. Это тоже самое, что и репозиторий, только конкретно типизированный под бд. Т.е. это одна и та же концепция.

У них разные задачи. Репозиторий может совершенно не знать как именно хранятся данные. Попробуйте глянуть на это с такой точки зрения: вам надо протестировать отдельно бизнес логику и отдельно правильное создание бизнес объектов юнит тестами. Как вы бедете изолироваться от хранилища, если все свалите в один класс?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Gattaka, Вы писали:

G>>Здравствуйте, IT, Вы писали:

IT>>>От хранимок нужно избавлятся при первом удобном случае. Логика в БД — это сегодня нонсенс.
G>>Красивый сказка, которая не выдерживает проверку практикой. При большее детальном рассмотрении запросов, создаваемых ORM выясняется что сильно не эффективны. Нужно избавляться от кодогенратов во всех их проявленяих в том числе и от ORM.
G>А можно пример? На моей практике люди сильно хуже пишут запросы в sql, чем на linq. Тем более последний отсекает ряд банальных ошибок, из-за которых запросы могут тормозить.

Эпическое движение стиля кодирования.
Помню, сначала писали SQL-стейтменты в коде.
Потом информации о том, как это плохо поддерживать появилось больше и начали перемещать стейтменты в хранимки.
Потом появился linq. SQL-стейтменты снова оказались в коде.
Теперь снова появляется много информации о том, как это хреново поддерживать...

Не пора ли уже остановиться?

Здравствуйте, another_coder, Вы писали:

_>Эпическое движение стиля кодирования.
_>Помню, сначала писали SQL-стейтменты в коде.
_>Потом информации о том, как это плохо поддерживать появилось больше и начали перемещать стейтменты в хранимки.
_>Потом появился linq. SQL-стейтменты снова оказались в коде.
_>Теперь снова появляется много информации о том, как это хреново поддерживать...

_>Не пора ли уже остановиться?

Не так все было.
С момента появления серверных СУБД было выгодно делать хранимки, они реально быстрее работали, чем adhoc запросы.
Ситуация кардинально поменялась в начале 2000-х, примерно в это время во всех популярных СУБД быстродействие adhoc запросов и хранимок сравнялась.
Тогда же появился холивар ХП vs запросы в коде. Оба подхода имели преимущества и недостатки.
Когда появился linq холивар можно было заканчивать. Ни одного реального преимущества у хранимок не осталось, кроме сценариев тупо не покрытых linq. Но холивар по привычке продолжился.
Относительно недавно появился linq2db, который покрывает любые сценарии работы с данными из приложения с помощью linq.

Здравствуйте, gandjustas.

Вообще, это интересная тема сравнить эффективность linq2db, linq2entities...

Здравствуйте, gandjustas, Вы писали:


S>>Вы смеетесь ??? Т.е. если Вы возьмете человека на фул-тайм с задачей написания sql запросов (специалиста), он больше одного запроса написать не сможет? Не считая того, что вообще говоря это должно быть компетенцией разработчика, отв. за соотв. таблицы (сущности).
G>Конечно сможет. И два сможет, и десять и может даже 50. Для статистики — у меня в очень простом приложении с 5 таблицами в базе получилось суммарно 60 разных запросов. А нанимать спеца отдельно по БД для базы менее чем два десятка таблиц никто не будет. Вот и посчитай какое количество запросов ему надо будет поддерживать.

Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.

Здравствуйте, Sharov, Вы писали:

S>Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.

И зачем разработчику поддерживать 10 почти одинаковых запросов на sql, а не одну функцию с linq и тремя if?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Sharov, Вы писали:

S>>Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.

G>И зачем разработчику поддерживать 10 почти одинаковых запросов на sql, а не одну функцию с linq и тремя if?

Если самописные быстрее, почему бы и нет?

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Sharov, Вы писали:

S>>>Каждый разработчик может самостоятельно поддерживать свои запросы. Спец не обязателен. Или он пишет и отдает разработчику, а тот в дальнейшем за запрос отвечает.
G>>И зачем разработчику поддерживать 10 почти одинаковых запросов на sql, а не одну функцию с linq и тремя if?
S>Если самописные быстрее, почему бы и нет?
А с чего они могут быть быстрее? И насколько они быстрее, что стоят десятикратного (а на деле больше) геморроя?

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, another_coder, Вы писали:

_>>Здравствуйте, gandjustas.

_>>На мой взгляд, вы не разделяете сущности от их технической реализации. В примере с тремя источниками данных, они все предлставляют собой одно и то же: хранилище данных. Для модуля системы, который использует хранилище данных, не важно что именно это (БД, IList, файл или web service). Весь функционал, который относится к доступу к данным спрятан там же и наружу не показывается. И вот тут как раз приходин на помощь объект, представляющий собой DAO. Конкретная его реализация может быть разной и зависить от уровня закладываемой абстракции в архитектуру. Это может быть EF, а может быть и просто объект с простым CRUD интерфейсом.

G>Ок, давайте конкретнее. Пусть у вас есть "хранилище данных" сотрудников.
G>Фактически это будет три разных хранилища:
G>1) Список в памяти — List<T>
G>2) База данных
G>3) Веб-сервис, который имеет только методы получения и сохранения по ID.

G>У вас задача поднять сотрудникам определенной категории зарплату на 10%.

G>Какой интерфейс универсального "хранилища данных" вы спроектируете для решения этой задачи.
G>Естественно писать заведомо неэффективный код — моветон.

var employees = await employeeRepo.GetEmployeesAsync(EmployeeCategory.SpecificCategory);
foreach (var employee in employees)
{
    employee.ChangeSalary(factor: +0.1f);
}
await Employee.SaveChangesAsync(employees);

Тут репозиторий знает откуда брать сотрудников (и их менеджеров, то есть репозиторий возвращает агрегаты из DDD), сотрудники знают как менять себе (в ООП лампочка вкручивает себя в люстру сама) зарплаты (все проверки и согласования с менеджерами внутри) и сохранять изменения. Хранилище тут находится уровнем ниже и используется репозиторием и сотрудниками — это может быть простой шлюз таблицы, обменивающийся с репозиторием и сотрудниками простыми объектами (DTO). И уже само хранилище владеет знанием откуда данные собственно берутся.

Зависимости:

Объекты предметной области -> объекты передачи данных -> объекты реализации (объекты EF, объекты веб-сервисов, а List<T> хранит объекты передачи данных)