Разработка механизма извлечения DTO из БД с помощью LINQ

[Nagg]

Чем выше абстракция — тем ниже производительность. Вы в своем решении судя по всему тупо выкинули Domain layer.

[mitro]

В последнем решении генерируются наиболее оптимальные SQL-запросы, поэтому производительность БД, наоборот, возрастает. Что касается производительности кода, то она такая же, как и при ручном написании LINQ-запроса, ведь дерево строится один раз в статическом конструкторе. И там, где скорости LINQ хватает, механизм можно смело использовать. По поводу Domain Layer немного не понял, что имеется в виду. Доменная модель присутствует. В статье описывается сценарий, когда надо просто получить данные и отдать их клиенту. Для выполнения бизнес-логики, конечно, из БД загружаются сущности и с ними производятся определённые операции.

[gandjustas]

Вы серьезно используете этот код когда есть WCF Data Services и WebAPI?

[Maxkn]

Безотносительно содержимого поста — вы пробовали взлететь с WCF и Web API?

[gandjustas]

Да, очень успешно. Был SL клиент, на нем модель, сгенерированная по WCF Data Services + немного JS, дергающих те же сервисы.

А недавно коллегами было сделано iOS приложение, которое работает с WebAPI и похожее, которое работает с OData.

[Maxkn]

Если не секрет — сколько DTO, сколько методов у сервисов? какой форматер? сериализацию/десериализацию не профилировали? сколько пользователей держит?

мы после полугода поедания кактусов переехали на protobuf — существенно быстрее стало. существенно.

[mitro]

Мне не доводилось использовать WCF Data Services в реальных проектах. Хочу воспользоваться моментом и спросить Вас, как человека, имеющего опыт работы с ними. С помощью них можно реализовать мультитенантность? И как проводятся проверки безопасности? К примеру, проверка прав пользователя и/или извлечение только тех сущностей, на которые у пользователя имеются ACL. Сейчас мы на сервере добавляем критерии в LINQ-запрос, который в конце отдаем в фетчер. Причем в зависимости от роли текущего пользователя мы определяем, надо ли проверять ACL или нет. И по разным типам запросов над одним типом данных такая логика может разнится.

[Nagg]

На WCF Data Services можно вставлять Interceptor's которые в зависимости от контекста могут фильтравать результаты.

[gandjustas]

Так и надо делать, а в чем проблема?

[mitro]

Мы все это делаем на сервере. Как я понял, фишка WCF Data Services в том, что запросы пишутся на стороне клиента. Проверка безопасности должна производиться на сервере. Из предыдущего комментария я понял, что для этого надо использовать Interceptors.

[mitro]

По поводу описанного кода — да, мы его используем. И он нас вполне устраивает, проект живет и быстро развивается. Вся логика запросов у нас находится на сервере и фетчеры являются одним из этапов (по факту, декларативно сконфигурированная проекция), которые проходит LINQ-запрос перед тем, как быть выполненным в БД. Перед этим он проходит через различные механизмы, навешивающим на него критерии поиска, безопасности и т.п. Плюс в проекте реализована мультитенантность и она хорошо легла в общую архитектуру. Data Services позволяют писать запросы на клиенте и еще возможно различные плюшки, о которых я пока не знаю, но это не значит, что теперь единственным правильным решением является их использование. Возможно, это действительно панацея (что редко бывает, так везде есть свои плюсы и минусы и разные задачи требуют разного подхода). В моих ближайших планах теперь хорошенько изучить WCF Data Services и составить свое мнение о них.

[gandjustas]

WCF DataServices работает с контекстом EF. Так что все равно сколько, хоть 100 будет. Форматтеры как обычно: atompub и json, встренные, вроде может можно поменять. Пользователей десятки-сотни были, полет нормальный. На фоне IO базы и передачи данных по сети сериализация\десерилизация не видна.

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