Инструмент ORM ИЛИ создайте объект для слоя реляционного отображения вручную - PullRequest
Новая
       16

Инструмент ORM ИЛИ создайте объект для слоя реляционного отображения вручную

2 голосов
/ 02 июля 2010

Я пытаюсь определить, что если при создании слоя данных используются какие-либо преимущества или недостатки в использовании уровня реляционного отображения объектов, такого как спящий режим или платформа Microsoft Entity.

Лучше ли использовать объекты sql и mapping объектов вручную в долгосрочной перспективе или лучше использовать одну из этих технологий отображения?

Кажется, что для простых приложений дополнительный слой отображения может быть выгоден, потому что инструмент может обрабатывать простое отображение и, следовательно, экономить некоторое время, но как быть, когда ваши объектные модели становятся более сложными?

Кроме того, каковы последствия для производительности, если таковые имеются?

Спасибо за ваше понимание.

Ответы [ 4 ]

4 голосов
/ 02 июля 2010

Лучший вариант - убедиться, что независимо от того, что вы делаете, у вас есть возможность изменить его позже.Так что, если вы переходите на NHibernate или EF, вам нужны фактические зависимости от фреймворков;То же самое для ручных реализаций.

Попробуйте реализовать шаблон Repository, затем вы можете создать NH-репо, EF-репо и т. д. и т. д. и посмотреть, какие из них лучше всего соответствуют вашим потребностям.

Myличное мнение состоит в том, чтобы сделать правильное OR-Mapping (вручную или с помощью фреймворка) - здесь подразумевается, что ваши бизнес / доменные объекты не просто выглядят как ваши таблицы, инаоборот.Весь смысл ORM заключается не только в том, чтобы вытащить данные из базы данных и в ваше приложение (для этого отлично подойдут DataSets), но и в том, чтобы позволить вам воспользоваться преимуществами ООП в вашем приложении иСУБД в вашем бэкэнде.

Если вы просто используете SQL в качестве «тупого хранилища» (мое любимое использование), то вы можете рассмотреть возможность использования OODB или другого подхода к сохранению объектов.Это всегда забавная вещь для изучения в хобби / побочных проектах - но это сложный случай для продажи руководству (они теряют свой SQL Server), но это стоит учитывать.

Конечно,если вы говорите об очень маленьком приложении, то, возможно, вы могли бы реализовать что-либо либо по шаблону Active Record, либо по шаблону Transaction Script - XScript отлично подходит для очень небольших приложений, но плохо масштабируется - и Active Record - отличнодля ввода данных / приложений CRUD

2 голосов
/ 02 июля 2010

Кажется, что для простых приложений дополнительный слой отображения может быть выгоден, потому что инструмент может обрабатывать простое отображение и, следовательно, экономить некоторое время, но как насчет того, когда ваши объектные модели становятся более сложными?

На самом деле, я бы сказал, что все наоборот.

Более разумно использовать ORM в более крупном приложении со сложной объектной моделью:

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

  • С другой стороны, с большим приложением, имеющим более сложную модель данных БД, легче ошибиться в своих JOIN и UPDATE и т. Д., Поэтому ORM может быть действительно полезным.

1 голос
/ 02 июля 2010

Вы можете создать свой собственный инструмент отображения ORM. Например здесь http://askcodegeneration.com/php/generate-propel-schema-for-php-symfony/

Схема propel orm генерируется из простого формата класса описания (ничто не мешает сделать это для любого другого языка, такого как c #, и любой платформы orm, такой как Hibernate, фактически в будущем я собираюсь это сделать): 

class-list: [question answer user interest relevancy]

Sample-Model: {

  class question [

    Id: 0
    title: ""
    body: ""
    created_at: 'now
    updated_at: 'now
    user_Id: [User]

  ]

  class answer [

    Id: 0
    question_Id: [question]
    user_id: [user]
    body: ""
    created_at: 'now
    updated_at: 'now

  ]

  class user [

    Id: 0
    first_name: ""
    last_name: ""
    created_at: 'now
  ]

  class interest [
    question_id: [question]
    user_id: [user]
    created_at: 'now
  ]

  class relevancy [
    answer_id: [answer]
    user_id: [user]
    score: 0
    created_at: now
  ]

}
1 голос
/ 02 июля 2010

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

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

Лично я не являюсь их поклонником - я думаю, что если вы на полпути разбираетесь в навыках работы с базами данных, то вам следует их использовать. Я думаю, что ORM, как правило, защищают разработчиков от сложностей с базами данных, что не всегда хорошо. Мне нравится настраивать доступ к данным и их хранение, и хотя написание кода для сопоставления наборов данных с объектами домена может быть утомительным, это не так сложно и не подвержено ошибкам, и я знаю точно , что происходит постоянно, волшебства нигде не происходит. Если есть проблемы с производительностью или неэффективность, я могу очень быстро их отследить и исправить.

...