Comments 14
Полезная тема, особенно с реализацией.
Вопрос — к хиберу куча дополнительных библиотек разрабатывается как самой командой хибера так и просто сторонними разработчиками. Не нашли готового решения?
Вопрос — к хиберу куча дополнительных библиотек разрабатывается как самой командой хибера так и просто сторонними разработчиками. Не нашли готового решения?
К сожалению не нашел.
Был проект на WCF, в котором имелся список методов сервиса с запросом в БД аля:
Решил избавиться от такого бардака, разработав свой велосипед, позволяющий писать эффективные запросы в сочетании с удобством разработки.
Был проект на WCF, в котором имелся список методов сервиса с запросом в БД аля:
IEnumerable<Message> GetMessagesOnLaskWeek();
IEnumerable<Message> GetMessagesOnCurrentDay();
IEnumerable<User> GetActiveUsers();
Решил избавиться от такого бардака, разработав свой велосипед, позволяющий писать эффективные запросы в сочетании с удобством разработки.
В момент вызова метода GetEnumerator() построенное дерево выражений будет не скомпилировано, а транслировано в sql-запрос.
При каждом запросе разбор происходит заново? Или есть некоторый кэш?
Есть некий кэш. Если углубляться в NHibernate, то Linq сначала преобразуется в Hql запрос, и только после этого преобразуется в SQL. Когда ковырял исходники, видел кэш Hql-запросов.
Извините, но чем не подошёл WCF Data Services, реализация OData для NHibernate? Я вижу как преимущества хорошо описанный протокол, контроль над тем, какие запросы допускается использовать клиенту, возможность простого вызова через любой http client, нет протекающих абстракций вида PostQuery.
Не подошел тем, что:
1) я не всегда использую http, бывает нужен и tcp.
2) WCF Data Services — это REST, а WCF Services — это SOAP. WCF Data Services — на мой взгляд, достаточно нишевая штука.
На счет PostQuery согласен — эта фигня мне тоже не особо нравиться, возможно в будущем доделаю код для динамического определения незамапленных свойств объекта на сервере.
PS: забыл добавить, что я не занимаюсь вебом, мой фронтенд — desktop и mobile.
1) я не всегда использую http, бывает нужен и tcp.
2) WCF Data Services — это REST, а WCF Services — это SOAP. WCF Data Services — на мой взгляд, достаточно нишевая штука.
На счет PostQuery согласен — эта фигня мне тоже не особо нравиться, возможно в будущем доделаю код для динамического определения незамапленных свойств объекта на сервере.
PS: забыл добавить, что я не занимаюсь вебом, мой фронтенд — desktop и mobile.
> Однако, если возникнет потребность в формировании запроса во внешнем процессе, например, в клиентской части сервиса, то в таком случае Reflection уже не спасет, клиентская часть, как правило, не знает (и не должна ничего знать) про серверный ORM.
ORM — это очень непростая штука, и она будет течь. Как минимум, далеко не каждый Expression сможет выполниться в NH. И не каждый ORM вообще поддерживает Linq.
Что бы абстракция работала — она должна быть максимально простой, чего тут нет.
Если вы просто выставляете БД наружу — зачем вам серверная часть? NH и mobile не дружат?
ORM — это очень непростая штука, и она будет течь. Как минимум, далеко не каждый Expression сможет выполниться в NH. И не каждый ORM вообще поддерживает Linq.
Что бы абстракция работала — она должна быть максимально простой, чего тут нет.
Если вы просто выставляете БД наружу — зачем вам серверная часть? NH и mobile не дружат?
ORM — это очень непростая штука, и она будет течь.
Не совсем понимаю, к чему это написано.
Как минимум, далеко не каждый Expression сможет выполниться в NH.
Мне и не нужен любой Expression, мне нужны expressions, которые наворачивают Linq-методы. В NH поддерживается большая часть методов linq.
И не каждый ORM вообще поддерживает Linq. Что бы абстракция работала — она должна быть максимально простой, чего тут нет
Я писал статью под названием linq2nhibernate, а не linq2AnyORM, когда встанет вопрос абстрагирования от конкретной ORM, тогда буду делать абстракцию.Пока что, over 9999 сценариев в моей работе закрывает NHibernate.
Если вы просто выставляете БД наружу — зачем вам серверная часть? NH и mobile не дружат?
1. Я хочу иметь удобный API, с помощью которого смогу писать селекты на клиенте, а выполнять их на сервере, чтобы не плодить кучу методов в WCF-сервисе
2 Я стараюсь придерживаться парадигмы CQRS, в которой Linq-запрос является (Q)uery, он не модифицирует БД, клиент вообще ничего не знает про БД, он знает, что есть удаленный репозиторий, из которого можно получать сущности.
3 Я писал в заключении — что можно докрутить expression с учетом своей системы авторизации, которая бы делала запрос с учетом разрешений пользовательского контекста.
> В NH поддерживается большая часть методов linq.
То есть у вас на клиенте «LINQ to NH» by desing? То есть у вас клиент знает про ОРМ и БД (жирным, 2 раза).
Тогда к чему написано процитированное мной «клиентская часть, как правило, не знает (и не должна ничего знать) про серверный ORM»?
> 1. Я хочу иметь удобный API, с помощью которого смогу писать селекты на клиенте, а выполнять их на сервере, чтобы не плодить кучу методов в WCF-сервисе
Не понял зачем вам WCF, и «выполнять» что-то на сервере (там же невозможно ничего выполнить, кроме оверхеда на ORM/WCF). Перенесите NH на клиент и сделайте для запросов обычную двухзвенку, будет удобный API и никаких методов для (Q)uery в WCF.
На вопрос «зачем вам серверная часть» ответ «хочу выполнять на сервере» несколько странный.
2, 3) В любой приличной БД авторизация для запросов уже есть. Хотя признаю, у неё, конечно, есть фатальный недостаток, как и у WCF с WCF DS.
Но применению CQRS и авторизации двухзвенка не противоречит, а весь код выше можно выкинуть.
Я просто не понимаю проблемы. Я могу представить, что хочется что-то выполнять на сервере(вычисления по сырым/секретным/сложным данным), но тогда это будут точно не linq запросы с клиента.
А без авторизации это просто бэкдор.
То есть у вас на клиенте «LINQ to NH» by desing? То есть у вас клиент знает про ОРМ и БД (жирным, 2 раза).
Тогда к чему написано процитированное мной «клиентская часть, как правило, не знает (и не должна ничего знать) про серверный ORM»?
> 1. Я хочу иметь удобный API, с помощью которого смогу писать селекты на клиенте, а выполнять их на сервере, чтобы не плодить кучу методов в WCF-сервисе
Не понял зачем вам WCF, и «выполнять» что-то на сервере (там же невозможно ничего выполнить, кроме оверхеда на ORM/WCF). Перенесите NH на клиент и сделайте для запросов обычную двухзвенку, будет удобный API и никаких методов для (Q)uery в WCF.
На вопрос «зачем вам серверная часть» ответ «хочу выполнять на сервере» несколько странный.
2, 3) В любой приличной БД авторизация для запросов уже есть. Хотя признаю, у неё, конечно, есть фатальный недостаток, как и у WCF с WCF DS.
Но применению CQRS и авторизации двухзвенка не противоречит, а весь код выше можно выкинуть.
Я просто не понимаю проблемы. Я могу представить, что хочется что-то выполнять на сервере(вычисления по сырым/секретным/сложным данным), но тогда это будут точно не linq запросы с клиента.
А без авторизации это просто бэкдор.
То есть у вас на клиенте «LINQ to NH» by desing? То есть у вас клиент знает про ОРМ и БД (жирным, 2 раза).
Вы выдергиваете слова из контекста, сначала написали про непереваривания NH любого expression, я вам ответил, что то, что нужно, он переварит. А про то, что он не может переварить знает валидатор клиентских expression'ов.
На вопрос «зачем вам серверная часть» ответ «хочу выполнять на сервере» несколько странный
это вопрос по области применения, опять-таки возвращаюсь к своему примеру, в проекте, который меня побудил сделать это, часть бизнес логики, критичной к безопасности и масштабированию, выполнялась на сервере. Разумеется, в простом случае, описанном вами, нет никакого смысла применять такое решение. WCF используем, как стандартный транспорт.
А без авторизации это просто бэкдор.
Авторизация запроса — тема, выходящая за рамки данной статьи (которая и так получилась тяжеловатой для восприятия)
> А про то, что он не может переварить знает валидатор клиентских expression'ов.
То есть у вас есть валидатор, заточенный на NH.
> в проекте, который меня побудил сделать это, часть бизнес логики, критичной к безопасности и масштабированию, выполнялась на сервере.
Как Query? То есть у вас 2 механизма выполнения запросов (которые не команды)?
То есть у вас есть валидатор, заточенный на NH.
> в проекте, который меня побудил сделать это, часть бизнес логики, критичной к безопасности и масштабированию, выполнялась на сервере.
Как Query? То есть у вас 2 механизма выполнения запросов (которые не команды)?
А как быть например с полнотекстовым поиском?
Ну, если вы делаете Contains по текстовому свойству например, то для него придётся написать Visitor, если я ничего не путаю.
Собсна, пишите код на клиенте, смотрите что упало, чините =)
ПС: нормальный полнотекстовый поиск всё равно надо делать иначе, с индексами, с кучей заморочек. Имхо, не тема статьи.
Собсна, пишите код на клиенте, смотрите что упало, чините =)
ПС: нормальный полнотекстовый поиск всё равно надо делать иначе, с индексами, с кучей заморочек. Имхо, не тема статьи.
Профит тонет в абстракциях и сериализациях. Я хочу сказать, что выглядит это круто, особенно с Mock запросом, но на практике это только увеличит сроки разработки и ничем не поможет поддержке. Учитывая подход «Я использую 100% только NHibernate и вряд ли уйду на что-то другое» — смысла городить такую абстракцию не вижу. Но решение крутое. Жаль, что решение ради решения, которое ничего в общем-то не решает.
Sign up to leave a comment.
Client-side Linq to NHibernate