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

Question

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

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

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

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

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

Answer 1

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

Попробуйте реализовать шаблон хранилища, вы могли бы построить NH-repo, EF-repo и т. Д. И т. Д. И посмотреть, что вам подходит лучше всего.

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

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

---

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

Answer 2

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

Фактически, я бы сказал, что все наоборот.

Это имеет смысл использовать ОРМ в более широком применении, который имеет сложную объектную модель:

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

• С другой стороны, с большим приложением, имеющим более сложную модель DB данных, это легче получить ваши JOIN с и ваш UPDATE s и т.д. неправильно, поэтому ОРМ может быть действительно полезным.

Answer 3

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

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

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

Answer 4

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

Схема передвижения ОРМА генерируется из формата простого описания класса (ничто не мешает сделать это для любого другого языка, как C# и любых рамки ОРМА, как 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 
    ] 

} 

Answer 5

Ну Ayende имеет хороший пост о why you should not build your own ORM (DAL)