структура данных объекта - 101

Question

Я привык использовать наборы данных для своих проектов с точки зрения доступа к данным.Теперь я настроил себе простое приложение для работы, чтобы изучать структуру данных сущностей и как извлекать данные и манипулировать ими.

Все учебные пособия и примеры, которые я нашел в Интернете, слишком сложны для меня.

Может кто-нибудь подсказать мне, с чего начать, каковы преимущества этой модели, в каких сценариях я должен выбрать использование структуры сущностей и каковы вещи (основы), которые я должен сейчас перед началом.

Мои наборы данных тоже работают нормально.Есть ли у меня причины не придерживаться такого способа доступа к данным?Или это то, что следует учитывать в зависимости от пользователей сайта (в целях скорости и т. Д.)

Любая информация - руководство будет оценено.

Заранее спасибо.

Answer 1

Я согласен со всеми замечаниями Адама Робинсона, но я бы добавил, однако, что переход на ORM (в моем случае EF4.0) был , все о продуктивности разработчиков .Ранее я использовал все классы и методы доступа, закодированные вручную, и тщательно создавал хранимые процедуры для любого доступа к данным - и, откровенно говоря, производительность никак не могла быть достигнута ничем - но все это ручное кодирование требует много времени.

Я бы, по самым скромным подсчетам, сократил большинство моих усилий по разработке вдвое, используя EF4.0 вместо моих старых методов, и мои пользователи не заметили заметного замедления.В тех немногих случаях, когда мне нужна дополнительная производительность, я все еще могу вручную закодировать доступ к некоторым данным и / или хранимую процедуру, чтобы получить дополнительную информацию, когда это необходимо.

Так что, в ответ на ваш вопрос, ничего нет«неправильно» в вашем способе ведения дел, но вы должны пройти весь процесс изучения ORM, а затем посмотреть, не перевесят ли они плюсы за вас.

Answer 2

Вопрос, который вы задаете («Когда мне следует использовать ORM, а не DataSets / жестко-закодированный SQL?»), Является слишком широким, чтобы его можно было адекватно рассмотреть на веб-сайте вопросов и ответов. Тем не менее, вот несколько важных моментов:

• ORM обеспечивают безопасность, потому что они генерируют классы из таблиц в вашей базе данных (или наоборот, если вы решите пойти по этому пути), и вы выполняете свое взаимодействие в коде с этими классами вместо встраивания имен полей и таблиц в ваш код. Это обеспечивает вам безопасность во время компиляции, гарантируя, что вы не откроете один из них и не обнаружите его скрытым в глубине своего приложения через шесть месяцев после его развертывания.
• ORM предоставляют более естественные средства доступа к связанным сущностям (я могу делать такие вещи, как 'customer.Orders' или 'order.Customer' в коде), а не встраивание SQL в строку или доступ ко всему через хранимые процедуры

И пара недостатков

• Во всех операциях, кроме самых простых, генерируемый ORM SQL, вероятно, будет медленнее, чем SQL, созданный вручную или хранимые процедуры. Вы используете ORM для безопасности и удобства, а не для скорости.
• Легко использовать такие функции, как отложенная загрузка (когда связанные сущности загружаются по требованию, а не сразу), и снижать производительность, не осознавая этого.
• Чтобы в полной мере использовать ORM (то есть отношения и использовать его во время обновлений, удалений и вставок), вам, как правило, приходится возвращать в память весь объект, а не только его часть.

Answer 3

Кривая обучения для ORM (любая ORM) является значительной.Не позволяйте упрощенной генерации кода в начале процесса обмануть вас.

Если бы кто-то знал как ORM, так и наборы данных, я думаю, что они выбрали бы ORM в 99% случаев, преимущества в этом неоспоримы.ORM не идеальны, но они намного лучше, чем наборы данных почти в каждом сценарии.

Тем не менее, если наборы данных работают на вас, а кривая обучения ORM ставит вас в тупик, то вполне нормально придерживатьсяс наборами данных.Я бы посоветовал вам продолжать идти по кривой обучения для ORM, даже если на это уходят годы обучения (и это может произойти).