Pull to refresh
23
0
Aleksandr Goida @ETman

Software Developer

Send message
Мне необходимо понять о чем именно вы говорите.
Вы считаете CRUD-интерфейс — это нормально для репозитория? Я о таком, где, например:
IList Load()
void Update(T item)
void Add(T item)
void Delete(T item)

Или в репозитории должны быть методы типа, но не CRUD:
IList GetItemsBy(int id)
IList GetItemByParent(TParent p)

?
понял. согласен с тем, что выше.
Вы про сервис из DDD?
Если у вас в репозитории только linq запрос или вызов хранимки, разве это репозиторий? Это «тупой» DAO.
Вы считаете это элементы бизнес-слоя?
Не стоит полагать за меня и копаться в деталях. Если рассматривать детально, то одного поста не хватит.

Про BO — это пример эскалации абстракции, из-за которой репозиторий является, по вашим словам, абстракцией над доступом к данным. Кратко, А использует B, использующее С => A использует С.

Генерацию запросов надо помещать за репозиторий.

Верно. И это делает EF, например.

По-моему, мы об одном и том же.

Он такая же абстракция над доступом к данным, как бизнес-объект. У него выхода нет и по цепочке ответственностей, конечно, он абстрагирует. Но куда поместить, например, поместить джойны, генерацию запросов и куда, скажем, системную нотификацию об операциях? Обычная связка: linq-запрос по EF Code First + бросить в очередь сообщение, которое отправится потом другой службой. Что есть что тут и как построить систему. Люди сваливают все это в одно место, не заботясь о разделении, когда думают, что все это — работа с данными. По факту, есть 1) linq-запросы с EF, 2) нотификатор и, что неочевидно некоторым, 3) логика в репозитории создающая сложные BO. Если смотреть с точки зрения тестирования этого всего, то 1) надо будет отделить от 3).
Возможно, частный случай, но, как мне кажется тут и возникает нестыков. Одни полагают, что можно все свалить в одно место, т.к. собираются тестировать руками, а не тестами.
Следите за мыслью?
В некий бизнес-объект?
Проблем с тестированием этого не возникнет? В одной сущности намешано несколько вещей (SPR не соблюдается), как я вас понимаю.
В общем, так и есть. Но некоторые считают, что репозиторий не для абстракции хранилища данных, а для абстракции доступа к данным. Из-за этого разница в понимании целей возникает. О чем я и написал.
В следующей будет обзор.
аргументируйте, плиз?
XML умышленно не стал рассматривать, т.к. для этого нужна отдельная статья. В добавок Spring не хочу, т.к. он мне так же не нравится, как и Unity.
Если действительно там должно, значит не сориентировался. Следующей статьей исправлюсь.
пост, конечно, старый, но может кто-то его прочитает и не поймет, что то, о чём вы говорите, реализовано в xUnit с помощью Fixtures. На счет fluent-assertions не в курсе.

Information

Rating
Does not participate
Location
Lozenets, Sofiya, Болгария
Date of birth
Registered
Activity