А проект действительно крупный?
Меня недавно от такого шага остановило то, что в .NET Core по бороде пошел Reflection API, который я активно использовал
Я бы и билдеры выбросил, да и это не билдеры, а фабрики по сути.
Несколько лет назад, когда изучал WPF, мой мозг был затуманен подобными статьями, где обязательно былa ViewModel, даже там, там где она не нужна (например свойства модели тупо копировались во вью-модель). Боюсь на новичков эта статья произведет такой же эффект, как и на меня когда-то, а именно, слепая вера, что вью модель — наше все, а по сути лишняя прокладка.
Был бы пример нагляднее, где без ViewModel ну никак.
1) Имхо, для тестов, способ 3 — самый годный. Плюс лямбда-геттер надо бы закэшировать.
Имхо, вложенный класс для раскрытия состояния (конкретно для тестовых случаев) — способ неправильный и нагружает класс лишним знанием о том, что кто-то должен будет к приватному члену обратиться. Лучше поправить упавшие тесты при рефакторинге приватного члена, на который тесты заточены, чем вносить лишнюю ответственность в класс.
2) Тестировать внутреннее состояние не совсем правильно, ибо по канонам ООП, класс должен обеспечивать корректную работу с внешней средой через публичный API. А как он это делает внутри — его личное дело.
То есть у вас на клиенте «LINQ to NH» by desing? То есть у вас клиент знает про ОРМ и БД (жирным, 2 раза).
Вы выдергиваете слова из контекста, сначала написали про непереваривания NH любого expression, я вам ответил, что то, что нужно, он переварит. А про то, что он не может переварить знает валидатор клиентских expression'ов.
На вопрос «зачем вам серверная часть» ответ «хочу выполнять на сервере» несколько странный
это вопрос по области применения, опять-таки возвращаюсь к своему примеру, в проекте, который меня побудил сделать это, часть бизнес логики, критичной к безопасности и масштабированию, выполнялась на сервере. Разумеется, в простом случае, описанном вами, нет никакого смысла применять такое решение. WCF используем, как стандартный транспорт.
А без авторизации это просто бэкдор.
Авторизация запроса — тема, выходящая за рамки данной статьи (которая и так получилась тяжеловатой для восприятия)
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 с учетом своей системы авторизации, которая бы делала запрос с учетом разрешений пользовательского контекста.
Не подошел тем, что:
1) я не всегда использую http, бывает нужен и tcp.
2) WCF Data Services — это REST, а WCF Services — это SOAP. WCF Data Services — на мой взгляд, достаточно нишевая штука.
На счет PostQuery согласен — эта фигня мне тоже не особо нравиться, возможно в будущем доделаю код для динамического определения незамапленных свойств объекта на сервере.
PS: забыл добавить, что я не занимаюсь вебом, мой фронтенд — desktop и mobile.
Есть некий кэш. Если углубляться в NHibernate, то Linq сначала преобразуется в Hql запрос, и только после этого преобразуется в SQL. Когда ковырял исходники, видел кэш Hql-запросов.
С одной стороны вопрос регулирования контента и доступа к контенту достаточно важен и должен быть проработан.
С другой стороны, за что бы не бралось правительство РФ в сфере информационных технологий — почти всегда вместо целостной методологии получается франкенштейн.
Да ладно, сравните зп java senior developer (web) или asp.net senior developer и embedded system developer (в Москве, например).
Я 4 года назад, когда стоял на распутье: разрабатывать софт под железо или писать на шарпике, выбрал шарпик, потому что семью кормить тоже нужно.
У отчета может быть не read модель?
Меня недавно от такого шага остановило то, что в .NET Core по бороде пошел Reflection API, который я активно использовал
Это же какой-то кошмар. Если приводите код на c# будьте любезны писать код на английском языке.
Несколько лет назад, когда изучал WPF, мой мозг был затуманен подобными статьями, где обязательно былa ViewModel, даже там, там где она не нужна (например свойства модели тупо копировались во вью-модель). Боюсь на новичков эта статья произведет такой же эффект, как и на меня когда-то, а именно, слепая вера, что вью модель — наше все, а по сути лишняя прокладка.
Был бы пример нагляднее, где без ViewModel ну никак.
Имхо, вложенный класс для раскрытия состояния (конкретно для тестовых случаев) — способ неправильный и нагружает класс лишним знанием о том, что кто-то должен будет к приватному члену обратиться. Лучше поправить упавшие тесты при рефакторинге приватного члена, на который тесты заточены, чем вносить лишнюю ответственность в класс.
2) Тестировать внутреннее состояние не совсем правильно, ибо по канонам ООП, класс должен обеспечивать корректную работу с внешней средой через публичный API. А как он это делает внутри — его личное дело.
Вы выдергиваете слова из контекста, сначала написали про непереваривания NH любого expression, я вам ответил, что то, что нужно, он переварит. А про то, что он не может переварить знает валидатор клиентских expression'ов.
это вопрос по области применения, опять-таки возвращаюсь к своему примеру, в проекте, который меня побудил сделать это, часть бизнес логики, критичной к безопасности и масштабированию, выполнялась на сервере. Разумеется, в простом случае, описанном вами, нет никакого смысла применять такое решение. WCF используем, как стандартный транспорт.
Авторизация запроса — тема, выходящая за рамки данной статьи (которая и так получилась тяжеловатой для восприятия)
Не совсем понимаю, к чему это написано.
Мне и не нужен любой Expression, мне нужны expressions, которые наворачивают Linq-методы. В NH поддерживается большая часть методов linq.
Я писал статью под названием linq2nhibernate, а не linq2AnyORM, когда встанет вопрос абстрагирования от конкретной ORM, тогда буду делать абстракцию.Пока что, over 9999 сценариев в моей работе закрывает NHibernate.
1. Я хочу иметь удобный API, с помощью которого смогу писать селекты на клиенте, а выполнять их на сервере, чтобы не плодить кучу методов в WCF-сервисе
2 Я стараюсь придерживаться парадигмы CQRS, в которой Linq-запрос является (Q)uery, он не модифицирует БД, клиент вообще ничего не знает про БД, он знает, что есть удаленный репозиторий, из которого можно получать сущности.
3 Я писал в заключении — что можно докрутить expression с учетом своей системы авторизации, которая бы делала запрос с учетом разрешений пользовательского контекста.
1) я не всегда использую http, бывает нужен и tcp.
2) WCF Data Services — это REST, а WCF Services — это SOAP. WCF Data Services — на мой взгляд, достаточно нишевая штука.
На счет PostQuery согласен — эта фигня мне тоже не особо нравиться, возможно в будущем доделаю код для динамического определения незамапленных свойств объекта на сервере.
PS: забыл добавить, что я не занимаюсь вебом, мой фронтенд — desktop и mobile.
Был проект на WCF, в котором имелся список методов сервиса с запросом в БД аля:
Решил избавиться от такого бардака, разработав свой велосипед, позволяющий писать эффективные запросы в сочетании с удобством разработки.
С другой стороны, за что бы не бралось правительство РФ в сфере информационных технологий — почти всегда вместо целостной методологии получается франкенштейн.
Может быть просветите о разнице в терминах?
Сходу не нашел информации о различии в интернетах.
Это какие?
Я 4 года назад, когда стоял на распутье: разрабатывать софт под железо или писать на шарпике, выбрал шарпик, потому что семью кормить тоже нужно.
Сирьезна???