KorbanzЗдравствуйте. Подскажите как лучше организовать запросы клиента (на C#) к бд (postgresql):
написать хранимые процедуры и вызывать их из клиента или зашивать sql запросы в сам клиент(этого делать не хочется) или есть ещё какие-то способы?
* надо три слоя - презентации, бизнес-слой, слой доступа к данным
* опционально бизнес-слой можно соединить со слоем презентации, если в нем использовать MVP/MVVM паттерн, иначе отдельные бизнес-службы в DI-контейнер
* слой доступа к данным в виде абстракции ObjectQuery или Repository, в которых можно конкретно реализовать любой подход для доступа к данным, их тоже в DI-контейнер

выбор БД:
* для обычного CRUD приложения с небольшими объемами данных лучше использовать MS SQL Express, который бесплатный и лучше дружит с человеком
* если есть особенности - то надо изучать их и тогда выбирать БД

выбор технологии для слоя доступа к данным:
* для обычного CRUD приложения с небольшими объемами данных и MS SQL Express лучше всего подойдет LINQ-to-SQL, там тоже можно написать хранимые процедуры, но это будет означать распределение бизнес-логики по нескольким местам, что увеличивает сложность => больше ошибок

можно предположить следующие особенности и проблемы:
* большой объем данных:
- общепризнанные ORM имеют проблемы с обработкой больших объемов данных, например EF имел утечку памяти при обработке больше 20000 объектов в одной транзакции
- некоторые общепризнанные ORM имеют проблемы с операциями над сущностями, когда сначала надо сделать select, а потом update (этим страдает LINQ-to-SQL, в EF в более поздних версиях - оптимизировали это, NHibernate 3 умеет через метод Load)
* работа через dto
- когда результат запроса является dto, собранным из нескольких таблиц БД, то появляются проблемы дальнейшей пакетной обработки записей, например для 50000 таких записей надо считать некое поле, затем поменять его значение по определенной логике, а после обновить в БД - EF в таких условия сдается, мало того, что у него утечка памяти, так и еще MS SQL ограничивает длину запроса, что делает невозможным достать по Id с использованием конструкции WHERE ... IN ... 50000 записей, танцы с бубном со средствами построения нативных sql запросов решения не дали
* бизнес-логика, для которой достаточно данных в БД и возможностей языка SQL:
- если бизнес-задача (алгоритм) может быть решена в рамках БД и языка SQL, то тащить данные на клиент, выполнять эту логику и обновлять в БД - работает дольше и сложнее в реализации, чем выполнить это все на стороне БД в хранимых процедурах, плюс если объем данных велик - проблемы умножаются
- но при использовании MS SQL есть бонус - подключение C# кода прям в SQL запрос, работате немного медленней, не все гладко с преобразованием типов, но зато все возможности C#
* длинные распределенные транзакции, тут надо смотреть откуда они зародились

в выше описанных ситуациях - можно рассмотреть использование хранимых процедур

другие проблемы:
* ORM предполагалась как решения проблемы кросс-платформенности, но в реальности это не всегда так, например различия автоинкрементного поля в Oracle (sequence) и MS SQL 2000-2008 (identity) или ограничение идентификатора в Oracle 10g в 30 символов

фиганычKorbanz,

wcf + хранимые процедуры.

почему wcf:
1. Можешь прикрутить SSL для клиент/серверного обмена
2. Можно разворачивать на IIS и юзать кэширование для сложных/долгих запросов.
3. Не нужно никого клиента баз данных на самом клиенте.
3. Ну и стандартные плюсы трехзвенки.

почему хранимые процедуры:
1. В опу запуск SQL с клиента рассадник sql-инъекций.
2. Статичный SQL запрос проще/лучше оптимизировать.
3. При обновлении структуры базы ты сразу же обновляешь запросы, а не выискиваешь эти запросы в коде клиента - причём некоторые запросы вылазят не сразу, а со временем.
4. Проще разграничивать права доступа - дал права на процедуры/пакеты, а не на таблицы/вьюхи.

почему wcf:
1. а если не надо?
2. а если не надо? и можно юзать иные способы кэширования, в СУБД тоже есть кэш
3. зато нужен клиент для WCF

почему хранимые процедуры:
1. кодирование
2. +
3. в случае использования ORM не требуется править запросы
4. не факт

МСУАлексей Кпропущено...
LINQ2SQL!
главное шоп не ублюдочный кодефирст.
как то в итоге с ним быстрее работается:
1. добавил поле в класс, добавил маппинг, нажал развернуть базу => профит
2. добавил поле в БД, пошел в дизайнер, нажал обновить, оно потупило минуты 2-3-5, кинуло в дизайнер кривой класс, пошел править класс, исправил => профит

Cat2Масштабируемость? Чем она выше, чем в двузвенке? Она зависит от от возможностей СУБД, а не от способа доступа. И среднее звено ее может только понизить.
* во-первых "N-tier" - это физическое разделение (разные сервера), да это замедляет
* во-вторых "Layer" (слой) - это логическое разделение, в какой-то меньшей степени это тоже замедляет
* но, если добавить слой служб (сервер приложений) - можно поставить 10 БД, тем самым увеличив пропускную способность системы в целом
* чтобы достичь того же эффекта на клиент_с_логикой -> сервер_БД - необходимо делать прослойку, которая будет консолидировать данные с нескольких БД -> а это и есть третий слой, который если разместить на отдельном сервере выльется в 3-tier
* не для всех систем целесообразно делать слой служб/сервер приложений

Cat2Высокая безопаснеость? В чем она выше, чем при двузвенке?

Надежность трехзвенки не может быть выше надежности базы данных. Она обязательно будет ниже, так как включается ненадежность промежуточного звенеа.
все ерунда, как и через веб-сервер можно поломать все внутри, так и через сервер БД, смотря как настроена безопасность и там и там

SeVaрасскажи, как это можно организовать с помощью твоего говношипа, если разграничения доступа на уровне кубов и отчеты зависят от учетки
от учетки СУБД? тогда убрать зависимость от нее

вопросецвменяемый архитектор никогда не станет рассматривать СУБД только как хранилище
да, ее еще можно заставить делить таблицы и старые данные отделять, для ускорения запросов, это будет оттягивать момент создания второй БД-копии

netivanEf 5 рулит
оно уже умеет доставать 50 тыс записей по списку ID и без OutOfMemoryException ?

зы трехзвенка нужна:
- если потребителями является некое третье лицо, которому необходимо программное API
- потребителями являются некие другие платформы
- для масштабируемости и/или использования в шине данных

ViPRosновую книжку прочитал?
не понял наезда

ViPRosкакие проблемы из за чего пробемы) сэтим
>оно уже умеет доставать 50 тыс записей по списку ID и без OutOfMemoryException ?

а если по-русски написать? это вопрос был?

МСУ"Оно" и умело раньше, RTFM: MergeOption.NoTracking или AsNoTracking()

dto (ака вьюха) и entity разные вещи, пробовал в EF смержить две _разных_ entity ? что пишет? какой exception?

МСУЧушь на постном масле.

абаснуй

МСУПо первому пункту не торопи коней - а данные куда деваются после разворачивания, ась? Как-то у тебя всё просто - была БД с данными, добавили поле в таблицу и? Подскажу - нужно руками и в двух местах править, а в случае с дизайнером - в одном месте (класс перегенерится автоматом). Делай выводы.
во-первых - автоматом там ничего не перегенерится - я уже описал процесс с 2-3-5 минутным ожиданием
во-вторых - я описывал процесс при разработке, когда нет продакшена, при развертывании на продакшн в случае с database-first так же надо писать/генерить скрипт обновления данных в зависимости от ситуации
в-третьих - я разрабатывал database-first модель в EF и code-first модель в NHibernate + Fluent, и вот во втором случае все гораздо быстрее
в-четвертых - хотя да, дизайнера нет в NH, отношения сущностей все же лучше видны на ER-диаграмме

ViPRosугу, был вопрос
в чем суть проблемы с 50тыщ?
там несколько проблем было:
1. в базе, в таблице было порядка 300 тыс записей на тестовом и порядка миллиона на продакшене (они конечно еще были разбиты на группы, но один хрен в группе могло быть 50-100 тыс записей)
2. были функции, например:
* достать 50-100 тыс записей, точнее http URL из них (в поле хранилось), и просканировать все, получив ответ http 200/404, обновить статус в таблице в другом поле
* достать 50-100 тыс записей с вложенными объектами и сгенерировать для них определенные другие данные, потом сохранить это в БД
* вот в таких случаях, при вызове SaveChanges() в EF спустя некоторое время оно падало с OutOfMemoryException, в диспетчере задач было занято 99,99% из 2 Гб ОЗУ
3. был виндовый клиент, в котором был пейджинг и сложный фильтр, чтобы все это дело показывать пользователю, разумеется ему никто не вываливал мешок с миллионом записей, выводился dto, который из нескольких таблиц джоином и в виде .Select(e => new MyDto ...), по факту это работало аналогично родной вьюхе MS SQL
4. из виндовго клиента, после всяких фильтров и выделений записей на сервер приходило: либо условия запроса, либо условия запроса + список ID исключенных из обработки, либо только список обрабатываемых ID
5. соответственно:
* условия запроса работали для dto (вьюхи), но не всегда работал для entity, так как имена полей были разные и там были вложенности, была проблема переложения фильтра
* надо было исключать некоторые записи из обработки по ID, программно или дополнительным WHERE NOT IN
* надо было вытянуть 20 тыс записей по ID, если писать это через WHERE IN - то после 7000 с чем-то MS SQL выдавал, что шибко длинный текст запроса, давайдосвидания
* в некоторых случаях надо было для условия запроса / для указанных ID / нативного SQL запроса подгрузить сущности _вместе_ с вложенными объектами (чтобы их обработать), но не методом N+1, а джоином (Include в EF), и насколько я помню для нативного запроса - это не заработало в принципе, Include можно было включить для entity, но нельзя его включить для самописного нативного SQL, который возвращает тот же самый entity

МСУНе DTO, а отключение трекинга. Без трекинга ты не сможешь ничего мержить, еще раз - читай документацию. Фича конкретно под нужды. Ты спросил про чтение 50000 и OutOfMemoryException - я дал тебе рецепт. Теперь ты продолжаешь дальше генерить дополнительные условия. Определись. Если интересует конкретная задача - описывай подробно все нюансы, дам решение. А жалом водить из стороны в сторону будешь в детском саду.

вот тут я уже давно определился, читаем внимательней:

17-77- когда результат запроса является dto, собранным из нескольких таблиц БД, то появляются проблемы дальнейшей пакетной обработки записей, например для 50000 таких записей надо считать некое поле, затем поменять его значение по определенной логике, а после обновить в БД - EF в таких условия сдается, мало того, что у него утечка памяти, так и еще MS SQL ограничивает длину запроса, что делает невозможным достать по Id с использованием конструкции WHERE ... IN ... 50000 записей, танцы с бубном со средствами построения нативных sql запросов решения не дали

МСУОбосновал двумя страница ранее со ссылками на MS Application Architecture Guide.

книжку прочитал, думать головой разучился
17-77если потребителями является некое третье лицо, которому необходимо программное API
расскажи как будешь предоставлять бизнес-логику потребителям, которые сами захотят написать собственный клиент с блекджеком и шлюхами, а не юзать твою веб-/вин-морду? хранимки спасут не всегда, вдруг придется консолидировать информацию с нескольких источников
17-77потребителями являются некие другие платформы
протоколы передачи данных и всякие XML идиоты же придумали, правда? упразднишь? как данные передашь на другой континент? ком-объект заюзаешь? xDD

МСУВо-первых, автоматом генерится контекст, разумеется, через Run Custom Tool. Если ты не врубился, то речь о том, что не нужно сторонний гавнокод на t4 писать, всё нативно и в коробке.

для начала надо в дизайнер добавить сущность, а потом уже запускать run custom tool, а чтобы добавить сущность надо сделать процесс описанный мной в пункте 2, так что да я забыл туда дописать еще "нажать Run Custom Tool"

МСУТы нигде ничего не сказал про то, что эти два пункта относились к продакшену. Во-вторых, причем тут продакшен? На продакшене точно так же могут добавиться поля - и что, ты будешь сносить продуктовую базу и создавать с нуля? Тебя посодютъ (с)
Так что автоматическое создание базы для корпоративных задач - польза нулевая.

я и имел ввиду базу девелопера, это ты тут вспомнил про продуктовую базу и стал спрашивать про обновление данных:
МСУа данные куда деваются после разворачивания, ась?
так что не переворачивай слова, а тестовые данные на девелоперской базе заливаются с нуля скриптом и это проще и быстрее чем делать скрипт обновления

МСУДа однохерственно. Что на хибовом флюенте писать маппинги, что на EF. Непонятно, о каких микросекундах выйгрыша ты вещаешь.

кто-то тут говорил что code-first плоха штука, таки засеки сколько времени ты будешь через дизайнер добавлять сущности, в xml-объявлениях EF можно моск сломать, одно и тоже по два или три раза

МСУДизайнер есть для хиба, опять мимо.
не заливай, в самом NH дизайнера нет, про сторонние средства я в курсе

ViPRosа ты пробуй Join c пользовательским типом вместо In
ну если будет еще проект с EF, попробую, сейчас я все как-то на NH

ViPRosа так спс. значит еф как был гвоном так и остался
хорошо что не изучил
да незачто, но думаю с NH проблем не меньше будет, там я с другими сталкивался, например
* пейджинг + джоин для загрузки вложенных объектов, stackoverflow пестрит этой проблемой и нашли решение только через QueryOver с вложенным запросом и Distinct Transformer
* в одном уникальном случае, на довольно запутанной структуре БД NH.Linq падал, он не мог транслировать запрос в SQL, но там как бы и так видно, что надо переработать структуру БД
* еще меня волнует момент, когда в MS SQL можно было переносить условие WHERE в JOIN или простая группировка/агрегатные функции, обернутые в алиас таблицы, запросы ускорялись в разы - собственно можно ли такое в современных ORM замутить или нет