ORM по сравнению с уровнем доступа к данным Handcoded

Хорошо, это было для приложения PHP, а не .net one, но я думаю, что важны те же качества.

Несколько лет назад я переписал приложение для интрасети PHP, которое было основано на базе данных. Как типично для многих PHP-приложений, которые «только что выросли», они не использовали какой-либо ORM и имели много дублированного кода, большая часть которого собирала похожие запросы различными способами.

У меня был беглый взгляд на некоторые фреймворки ORM, но у всех них была большая проблема: им потребовалось бы настроить их для работы в нашей структуре. Большим отсутствующим компонентом была масштабируемость базы данных. Поэтому я написал свой собственный обработчик. Тогда было просто продолжать работать и создавать собственный слой данных на основе объектов. Мы получили возможность реализовать функции, которые хотели, и делали то, что нам нужно.

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

хороший вопрос и хорошие ответы. Я только что занялся этими вопросами. Я предпочитаю ORM, например, SubSonic, а кодировать DAL вручную

Я использовал Активную Рекордную реализацию Проекта Замка с NHibernate для персонального проекта. Проект никогда не развертывался, частично из-за моей неспособности работать с выбором ORM, который я сделал.

причина, что я решил использовать ORM, состояла в том, потому что я хотел способность переключиться от SQL Server до MySQL, не изменяя мой код. В реальных проектах решение использовать SQL-сервер уже принято для меня, и легче просто записать datalayers традиционным 3-уровневым способом, когда Вы знаете, что база данных не изменится. Но для персональных проектов я использую совместно использованный хостинг, и MySQL является более дешевым решением.

причина, я пошел с Замком, состояла в том, потому что это было очень просто в использовании. С activewriter плагином для Visual Studio я смог генерировать свои классы и базу данных с помощью разработчика (отчасти как linq разработчику SQL), и это, казалось, соответствовало хорошо моей умственной модели того, как ORM должен продиктовать архитектуру приложения.

проблема, которую я имел, с которым ORM был то, что я не смог найти информацию о том, как правильно оптимизировать ее. Это выполняло чрезвычайно большие вызовы к базе данных. (SQL-запрос, сгенерированный для получения пользователя, составлял 1 МБ текста, когда я зарегистрировал его.)

Так, я использующий ORM, я сохранил меня большая работа заранее, но я столкнулся со стеной, когда я пытался решить проблему с платформой, генерирующей слишком много SQL. (Над которым я все еще медленно работаю).

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

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

Вы не должны отказываться от своего SPROCs или SQL ручной работы с хорошим ORM как nHibernate.

я заменил свои методы доступа к данным ORM после факта, это не твердо вообще, это является лучшим из обоих миров.

Прокомментируйте свой вопрос о сохраненном процессе. Независимо от того, как будет написана функциональность, DAL, ORM, хранимые процессы, будет задействован SQL. Если вы используете хранимые процедуры, вы пишете SQL внутри, и в него довольно легко встроить полезные абстракции. Если вы используете DAL, вы пишете SQL, но на практике это скорее будет неабстрагированный SQL с повышенной подверженностью внедрению. Если вы используете ORM, инструмент записывает SQL-код (за который вы, тем не менее, в конечном итоге несете ответственность, включая инъекцию). ИМХО, чем меньше движущихся частей (особенно тех, которые вы знаете и понимаете), тем лучше.

Сохраненные Procs не удаляют риск внедрения SQL. Человек, который вероятен запросами concat в коде, так же вероятен сделать так в сохраненном proc. И любой хороший ORM не делает строки concats так или иначе, таким образом, нет никакой проблемы.

Я наследовал веб-приложение, которое было создано с NHib и MyGeneration, к сожалению, не получило svn repo и больше не имело начальные шаблоны (arrggg).

сохранили nhibernate для Создать/Обновить/Удалить материала бэкэнда, но фронтэнд (только для чтения), был несколько witlessly реализован, и выполнения как 2 собаки на ножках, и теперь переписывается в простом ADO.NET и подходит в 10 раз быстрее.

Am, не говоря, что это происходит из-за NHibernate, это происходит из-за разработчиков, не знающих, сколько дерьма они отправляли вдоль провода и предполагали, что вслепую использование инструмента будет означать, что они не должны были думать об этом.

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

Для вещей, которые должны записать в DB, обычно легче, и не что намного медленнее, чтобы позволить достойному ORM сделать это.

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

Инструменты являются большими, и что-либо, что дает мне, больше выходных является вдвойне большим, но нет никакой замены для инструмента между Вашими ушами.

Я боролся с этим в течение нескольких лет. Посмотревший много вещей. И имейте за прошлые 3 месяца, понятые, "почему я пропадаю впустую все это время на этом". Я вид представления ORM как решенная проблема. Я доверял бы некоторой команде, которая имеет полное внимание на ORM для записи уровня ORM, чем меня. Мысленно, я просто готов к новым проблемам.

Моим выбором является NHibernate. Я - действительно newb к этому прямо сейчас. Но мне нравится, когда потенциал использует Быстрый NHibernate или Замок ACtiveRecord также. Это, кажется, где доля завоеванного внимания.

, Но не уверенное, в чем я выполнил бы, "все - sproc" мир.

Несколько недель назад я запустил разработку на новом проекте. Я имел полный контроль над инструментами, которые я мог использовать. Я запустил с db40, потому что я хотел устранить этот вопрос в целом; я просто хотел сохранить свои объекты непосредственно, забыть о ADO.NET или OR/M. Но db40 имел проблемы так я ха для отказа от него.

Моим следующим выбором был ADO.NET, потому что я думал, что это будет быстро и легко. Но я должен был написать слишком много кода, использовать слишком много "строки sql", и это была просто тяжелая работа в целом. Я имею в виду, это был королевский ЛАВАШ, и после кодирования двух репозиториев с ним я хотел сократить запястья.

Моим третьим выбором был NHibernate. У меня были предыдущие проблемы с NHibernate в ситуации, где я должен был использовать разъединенные объекты (такой, имел место на этот раз также, следовательно почему мне потребовались три попытки добраться до него). Но это было NHibernate 1.2. На этот раз я получил эти 2,0 двоичных файла и имел нулевые проблемы с обновлением разъединенных объектов. Я также должен был записать пути меньше строк кода, и это было суперпросто, когда я должен был осуществить рефакторинг вещи, который был, вероятно, самым важным начиная с моего дизайна, измененного быстро.

я продаюсь на NHibernate теперь. Это кажется высоко оптимизированным также. Честно, я не могу найти отрицание к нему. И нет никаких хранимых процедур.

я знаю, что это - мой OR/M продвижения выбора, и я никогда не буду писать прямой ADO.NET снова.

Я писал и поддерживал свой собственный ORM в течение 8 лет теперь. Это запустилось в Java, затем переведенном в C#. Я не могу предположить писать, что любая база данных поддержала систему без него. Это - путь, более простой, чем NHibernate, и не имеет всех его функций, но это сделало задание, и это довольно быстро даже при том, что это использует отражение экстенсивно, так как это заменяет конфигурацию XML отражением по определениям классов ДАО.

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

РЕДАКТИРОВАНИЕ: относительно атак с использованием кода на SQL: недавняя система я разработал использование этого ORM, экстенсивно контролировалась, и абсолютно никакая инжекция не была разрешена. Причина проста: это генерирует SQL на лету и всегда параметры использования, никакая конкатенация строк.

Я использовал Дозвуковой для нескольких великоватых проектов. Я не защищаю использование одного ORM по другому, но я не сделал бы другого связанного с базой данных проекта без одного. Способность повторно создать весь слой доступа дб каждый раз, когда я изменяю структуру базы данных, способность добавить опции в одном месте, которые влияют на весь уровень DB.

вещь состоит в том, что необходимо понять, как это взаимодействует с базой данных, иначе Вы рискуете писать (сильно) неблагополучный код. Ваш инструмент ORM мог бы высказать Вам хорошее объектно-ориентированное мнение Ваших данных, но Вы могли бы найти потоковую передачу целых таблиц клиенту, чтобы сделать простую обработку. База данных способна связывать и фильтровать данные, поэтому удостоверьтесь, что это все еще имеет то задание. Как ни странно, отсутствие Subsonic соединений (в версии я использовал), помогло с этим, потому что это вынудило меня создать Представления DB для объединения данных при необходимости.

мой друг А работал с парнем, который разработал внутренний инструмент ORM. Это имело хорошую функцию локального кэширования всего, что Вы могли возможно хотеть от базы данных, сделанной путем обхода через внешние ключи. Оборотная сторона была то, что чтение одного столбца от одной строки в DB привело к избытку 11 000 избранных операторов.

I have been VERY successful simply using a DataSets in .Net. We have a SOAP endpoint that will first validate the input with an .XSD. Then, you can use a rules engine to do some validation. Then...

If the request is to insert data:

• Use GetXml() on the DataSet to convert to XML.
• Send the XML to a sproc that uses OPENXML in SQL Server.

If the request is to select data:

• Write a sproc to spit out the data with multiple SELECT statements.
• Load that data into a DataSet (being sure to build "nested" relationships where needed).
• Use GetXml() on the DataSet to covert to XML used in SOAP.

I've used this process with a great deal of success in several production environments. It's fast and simple if you know you'll only use SQL Server.

Вы пробовали красный боб? На стадии разработки он текуч и прост в использовании, а в режиме добычи (заморожен) - быстро. http://redbeanphp.com