ShSergebrainproof,

Вы немного (много) ошибаетесь. Проблема шустродействия не в ОРМ, а именно в том, как Вы работаете с базой.
Во-первых, никогда не пишите SELECT *, а не поленитесь написать используемые поля.
Во-вторых, никогда не используйте выборку без ограничений. Делайте выборку так, чтобы всё поместилось на одну страницу без прокрутки (наконец, пейжинг в помощь).
В-третьих, никогда не обрабатывайте данные в приложении, а только на сервере. А за селект, а тем более коннект в цикле - смертная казнь.

Как ни странно, Эти рекомендации вполне универсальные, не зависящие ни от ОРМ, ни от сервера БД.

Да это всё понятно и ежу. Речь о другом, о скорости намапливания данных на классы. Он утверждает, что его создание классов руками в конструкторе намного будет быстрее, я ему доказал обратное.

AntonariyВ области ORM я еще школота и пионер, но почитав мсдн, пришел к выводу, что в веб-проектах эта штуке не так уж удобна.
Несусветные глупости. Данные из может запрашивать что сайт, что десктоп, что веб-сервис, что вин-сервис, что консольное приложение. ОРМу абсолютно менопинисуально.

AntonariyЕсли что-то меняешь, то с большей вероятностью меняется таки .net-код, следовательно требуется переустановка приложения или его частей, то есть вероятна веселая возня с совместимостью, dll hell и т.п.
Какой-то поток сознания. Ничего не понял :)

AntonariyЯ пришел к тому, что .net-код код должен выполнять лишь следующие функции: 1) предоставить sql серверу в удобном виде то, что пришло с клиента; 2) собрать в единый документ несколько select for xml, применить к нему xsl и вернуть клиенту; 3) файловые операции.
Где мне купить такой дури, мембер?

handmadeFromRu, как-то не хочется распинаться перед серым ником (а ты пока им являешься). Подрастешь - потолкуем, а троллить иди лучше на ПТ.

ПарамонShSerge SQL-сервер позволяет гораздо больше, чем любая самая навороченная ОРМ (а г-кода в программе получается намного больше).

А можно в примерах? Кто чего может или неможет, бо ваш тролллинг на эту тему в каждой ветке - уныл и однообразен.

ps
SQL-сервер и ОРМ это разные понятия.

+1

С каждым днем я Сержа понимаю все меньше и меньше. Очень часто совсем бред какой-то пишет, даже комментировать не хочется.

Antonariy, бред сивой кобылы...

ShSergeОРМ - штука плохая исключительно из-за того, что SQL-сервер позволяет гораздо больше, чем любая самая навороченная ОРМ (а г-кода в программе получается намного больше) .
Я тебе уже пятьсот раз писал, что можно в орм юзать сторед объекты базы данных. Не доходит?

AntonariyМСУAntonariy, бред сивой кобылы... Я рад, что ты осознаешь цену своих высказываний, но смешного в этом мало.
Весьма странная радость осознавать, что твои ответы мало того неадекватны. Это весьма прискорбно, видеть деградацию форума в виде таких ответов, кои постаешь ты.


sphinx_mv, тайпед датасеты прошлый век. Более того это тупиковая ветвь эволюции, выраженная в реальных тормозах на больших схемах.

sphinx_mvВо-первых, на "больших схемах" (критерий, кстати, было бы не плохо предъявить) практической (реальной) разницы не будет никакой.
Ктитерий простой - тогда, когда начинает тормозить убогий дизайнер.

sphinx_mvВо-вторых... В каком-то месте запрещается разделение и комбинирование разных схем?
Про минусы разделения рассказать или сам догадаешься?

sphinx_mvВ-третьих. Действительно тупиковая ветвь эволюции - работать с базами данных, не имея представления ни о базах данных вообще
А кто сказал, что программист, использующий ORM, не имеет представления о базах данных?

sphinx_mvни о том, как с этими базами надо ПРАВИЛЬНО работать. Собственно, в этом и есть главная проблема с "тормозами на больших схемах".
А причем тут ORM? ORM помогает в 90% случаев уйти от рутины банальных запросов. В 10% никто не запрещает использовать сторед объекты, которые так же зарегистрированы в дата контексте. Можно "неправильно" работать с БД как с помощью ORM так и без оной.

sphinx_mvНу, и, в-четвертых... Делаем вид, что забыли про то, как на самом деле осуществляется доступ данных?
Да. По сути через все те же DbCommand, DataReader и DataAdapter...
Зачем нам забывать об этом или не забывать? Есть ORM, берем его и используем. В чему вопрос-то?

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

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

- Используйте ADO.NET Core, если:

Необходимо применить низкоуровневые API для управления доступом к данным в создаваемом приложении.

Необходимо использовать уже разработанные поставщики ADO.NET.

Используется традиционная логика доступа к данным базы данных.

Нет необходимости в дополнительной функциональности, предлагаемой другими технологиями доступа к данным.

Создаете приложение, которое должно поддерживать доступ к данным без подключения.

- Используйте ADO.NET Data Services Framework, если:


Хотите получить доступ к данным, предоставляемым как сервис через REST.
Используйте ADO.NET Entity Framework, если:

Концептуальная модель должна использоваться совместно приложениями и сервисами.

Необходимо сопоставить один класс множеству таблиц через наследование.

Необходимо формировать запросы к реляционным хранилищам, отличным от семейства продуктов Microsoft SQL Server.

Имеется объектная модель, которую необходимо сопоставить с реляционной моделью с помощью гибкой схемы.

Необходима гибкость отделения схемы сопоставления от объектной модели.

- Используйте ADO.NET Sync Services, если:

Необходимо создать приложение с поддержкой сценариев без постоянного подключения.

Используете Windows Mobile и хотите выполнять синхронизацию с центральным сервером базы данных.

- Используйте LINQ to Data Services, если:

Используются данные, возвращаемые клиентской частью ADO.NET Data Services.

Необходимо выполнять запросы к клиентским данным, используя синтаксис LINQ.

Необходимо выполнять запросы к REST-данным, используя синтаксис LINQ.

- Используйте LINQ to DataSets, если:

Необходимо выполнять запросы к Dataset, в том числе запросы на объединение таблиц.

Хотите работать с общим языком запросов, а не заниматься написанием итеративного кода.

- Используйте LINQ to Entities, если:

Используете ADO.NET Entity Framework.

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

Необходимо выполнять запросы к реляционным данным, используя синтаксис LINQ.

- Используйте LINQ to Objects, если:

Необходимо выполнять запросы к коллекции.

Необходимо выполнять запросы к папкам с файлами.

Необходимо выполнять запросы к объектам в памяти, используя синтаксис LINQ.

- Используйте LINQ to XML, если:

В приложении используются XML-данные.

Необходимо выполнять запросы к XML-данным, используя синтаксис LINQ.



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

По поводу спора про Linq 2 SQL.

Руководство MICROSOFT по проектированию архитектуры приложений Рекомендации по применению LINQ to SQL

LINQ to Entities рекомендуется применять для LINQ-запросов к реляционной базе данных. LINQ to SQL будет поддерживаться, но не будет основным объектом инноваций или доработок. Если вы уже применяете LINQ to SQL, можете продолжать использовать эту технологию. Но вновь создаваемые решений лучше реализовывать с LINQ to Entities. Более подробно эти вопросы рассматриваются в блоге группы разработки ADO.NET по адресу http://blogs.msdn.com/adonet

Так что юзать можно, но новые проекты разумно начинать на Entity Framework, как рекомендует MS. Тем более, что в четвёрке синтаксис сделали такой же и перестроиться на новые рельсы не составит труда.