Re[13]: Entity Framework за! и против!
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 18.08.14 18:40
Оценка:
Здравствуйте, Vladek, Вы писали:

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


V>>>Это зона ответственности репозитория, а снаружи ничего не известно и потому одну реализацию легко заменить на другую.

G>>Это в теории.

G>>А на практике разберем пример, что все посты хранятся в текстовом файле. Для простоты будем считать, что все оценки и комменты также хранятся вместе с постами (чтобы согласованность изменений была).

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

V>Нет, надо выбросить код с текстовыми файлами и написать код, работающий с БД.


Не понял фразы. Кому надо? Куда выбросить? Вот я тебе привет пример кода, который с субд работает. Ты предположил что репозиторий поможет "одну реализацию легко заменить на другую" и сам привел пример с файлами. В результате поменять субд на файлы окажется совсем нелегко, несмотря на репозитарии.

G>>Замена репозитария будет настолько маленькой проблемой, что её в этом контексте можно не рассматривать.

V>Что изменится в контракте репозитория? Правильно, ничего.

Даже если переписать весь контракт репозитария изменится 4-5 строк в методах, которые взывают этот репзитарий, по сравнению с написанием джоба по вычислению топовых постов, эти изменения не будут видны в микроскоп.


G>>Получается для того, чтобы "одну реализацию легко заменить на другую" нужно чтобы все стореджи поддерживали как минимум SQL, а это значит что они будут поддерживать Linq.

G>>Тогда зачем прятать Linq внутри репозитария, если можно IQueryable<T> отдать потребителю, а специфичные вещи спрятать в комбинаторы.

V>Потому что внешний мир обходится IEnumerable, отфильтрованным, отсортированным и порезанным на странички.

Ну ок, сделай все что надо непосредственно перед отдачей во внешний мир (в рендеринг страницы). Зачем тебе репозиторий?

V>ORM отдают IQueryable внешнему миру, а мы не пишем ORM, мы пишем репозиторий. Для нашего ORM весь внешний мир ограничивается репозиторием. А это значит, пользователь репозитория не имеет доступа к объектам ORM, которые маппятся из БД — нечего выдавать в качестве T для IQueryable<T>.

И какой в этом смысл? То что оно усложняет код я уже увидел, а где положительные эффекты?

V>>>Вместо строк можно использовать другие объекты, никаких ограничивающих правил нет.

G>>Какие например? Ну чтобы получить тот же уровень контроля компилятором, как в случае Linq.
V>PostSortingMethod.
Что это? Пример кода приведи.

V>>>Тогда сортировка просто не будет работать как надо, программист быстро укажет то, что нужно, и всё заработает.

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

V>Ещё программить может привести IQueryable к IEnumerable, отсортировать и в цикле выбрать нужные объекты. Компилятор с радостью это скомпилирует. И оно даже будет работать быстро некоторое время.

А кто мешает сделать программисту тоже самое с IEnumerable? Или ты думаешь, что если ты отдаешь IEnumerable. то никто к нему Linq применить не сможет, родив очень неэффективный код? Кстати именно поэтому имеет смысл отдавать Iqueryable, ибо тогда Linq превратится в запрос и улетит в базу, а привести к IEnumerable еще и не каждый догадается.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.