МСУРуководство MICROSOFT по проектированию архитектуры приложений Общие сценарии и решения

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

(skip...skip...skip...)


Если внимательно все это перечитать - мужики-то совсем запутались: то у них вода мокрая, то масло масляное. Все, что касается LINQ, копипастом разложили одно и то же по разным группам с повторениями (пару слов поменяли). В результате получилась рекламная пурга. По сути LINQ во всем этом полотне никакого отношения непосредственно к данным не имеет - работа идет с коллекциями объектов. В-общем, на то она и реклама - полет фантазии и растекание мыслЯми по дереву.

Кстати, я тоже так могу: "типизированная таблица в типизированном датасете представляет собой коллекцию типизированных строк"... Нигде не обманул? :)
МСУ1. Про убогий типизированный датасет ни слова. Раньше MS пиарило этот способ доступа, сейчас от него открещивается. Только редко в унылых старых проектах можно встретить этого монстра. Начинать же новые проекты или вести новую ветвь доработки на мертвой технологии - безумие.
К сожалению, не менее безумно использовать технологию, котрая еще толком не поддерживается другими производителями серверов БД...
По состоянию "на сейчас" имеем единственную (самую последнюю, меньше полугода возрастом) версию ODP.NET от Oracle, для которой указана поддержка EF. При этом глюки, которые вылезают при работе именно с этой версией не позволяют ее использовать для сопровождения старых разработок - при этом новые тоже никто отменять не собирается.

Терзают смутные сомнения, что аналогичная ситуация и на других, отличных от MSSQL платформах...
И, кстати, я в курсе, что виноваты в этом могут быть только их собственные разрабочики...
МСУ2. Как видно из рекомендаций MS, ADO.NET Entity Framework выгоден для моделей, которые повсеместно используются в приложениях и сервисах, другими словами для интеграции. Коими наша современная жизнь переполнена.
Рекомендации на самом деле следует воспринимать не как "выгодны", а как "может оказаться выгодным". При этом далеко не факт, что к моменту, когда его начнут "повсеместно" использовать, не придумают следующий, "еще более быстрый с простой" способ...
МСУ3. Конечно же, никто не запрещает использовать ADO.NET Core для низкоуровневого доступа к хранилищу с традиционной логикой доступа. Но смысл копаться в рутине, когда есть умные быстрые кодогенераторы, которые всю рутину делают за тебя, сосредотачивая разработчика на бизнес-задаче, а не на ковыряние в лохмотьях из селектов и апдейтов.
Ну, не знаю, что мы делаем не так... Но как селекты и апдейты те команды, которые у нас в проекте посылаются на сервер, никак не выглядят... :)

МСУsphinx_mvПо сути LINQ во всем этом полотне никакого отношения непосредственно к данным не имеет - работа идет с коллекциями объектов. В-общем, на то она и реклама - полет фантазии и растекание мыслЯми по дереву.

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

Я не говорю, что LINQ совершенно бесполезен...
Но пользы от него при работе именно с данными сильно меньше нуля...
Или мусье получать не обучен непосредственно с сервера только необходимые данные в нужной сортировке?
Целый язык доступа к колекциям, полезность которого начинается и заканчивается на обслуживании одного, не вложенного цикла по резалтсету - это такая немеряная круть!
МСУ
sphinx_mvК сожалению, не менее безумно использовать технологию, котрая еще толком не поддерживается другими производителями серверов БД...
EF - Microsoft Access,

А че не DBase?
МСУOracle
Мало?

Вы явно НЕ читаете что Вам пишут...
Сказано же - EF у Oracle "живет" аж целых полгода.
Ставить ЭТО на машину, на которой ведется реальная разработка - даже Вам посоветую.
МСУsphinx_mvПо состоянию "на сейчас" имеем единственную (самую последнюю, меньше полугода возрастом) версию ODP.NET от Oracle, для которой указана поддержка EF. При этом глюки, которые вылезают при работе именно с этой версией не позволяют ее использовать для сопровождения старых разработок - при этом новые тоже никто отменять не собирается.
Выкинь OracleClient и ODP.NET, возмьми Entity Framework, LINQ and Model-First for the Oracle Database
Пук в лужу... Вроде не заметно - а всем воняет...
Вы бы хоть пункт 3 пререквизитов по своей ссылке прочитали, что ли...
Да-да... Та самая глючная версия ODP.NET... Которую, к тому же, не буду показывать пальцем, кто-то хотел выкинуть...
МСУsphinx_mvТерзают смутные сомнения, что аналогичная ситуация и на других, отличных от MSSQL платформах...
Терзания выкинь в урну. Если нужно реально кросс базовое решение - NHibernate то, что доктор прописал.

Завелась шарманка про "кроссплатформенность"...
Меньше бы шарманщик читал дури на ночь - знал бы, что ни кросс-платформенности, ни кросс-базовости в природе НЕ существует... То есть - ВООБЩЕ...
МСУ
sphinx_mvИ, кстати, я в курсе, что виноваты в этом могут быть только их собственные разрабочики...
Виноват можешь быть только ты сам со своими типизированными датасетами. А разработчики тут не при чем.

А нету других решений! То есть - практически нет...
Теория хороша на бумаге, а не в проектах, которые нужно вовремя сдавать.
МСУ
sphinx_mvРекомендации на самом деле следует воспринимать не как "выгодны", а как "может оказаться выгодным". При этом далеко не факт, что к моменту, когда его начнут "повсеместно" использовать, не придумают следующий, "еще более быстрый с простой" способ...
Придумают, будем использовать. А что тут такого? Старое поддерживаем на старом, новое делаем на новом. А с такими темпами, о которых пишешь ты, мы бы доселе ездили бы на гужевых в повозках. Нравится? Флахвруки.
Детский сад, ясельная группа... Смешно (2 раза "ха")...
И сколько же раз Вы хотя бы участвовали в полной переделке проекта только на основании того, что появилась даже не новая, а просто чуть видоизмененная технология?
МСУ
sphinx_mvНу, не знаю, что мы делаем не так... Но как селекты и апдейты те команды, которые у нас в проекте посылаются на сервер, никак не выглядят... :)
А у меня эти селекты атоматом генерятся из такого же автоматического генеренного репозитория.
Автоматическая генерирация быдлокода "на потоке"?
Песец!!! (полярный пушной зверек)...