Каково различие между ORM, AR, QB, & DM?
Есть еще одно свойство, которое имеет функция JavaScript. Если вы хотите вызвать ту же анонимную функцию рекурсивно.
(function forInternalOnly(){
//you can use forInternalOnly to call this anonymous function
/// forInternalOnly can be used inside function only, like
var result = forInternalOnly();
})();
//this will not work
forInternalOnly();// no such a method exist
3 ответа
Sun Microsystems и Microsoft постоянно делают это с помощью Java и C #. Давайте возьмем что-нибудь простое и дадим ему новое имя! Какая отличная идея.
Если вы скажете ORM ... все знают, что это такое, во многих его проявлениях. Однако ваш код выглядит как материал Linq.
Никакой магии, но куча модных словечек и суеты ИМХО.
Согласовано с @Aiden Bell. Но я думаю, что вы правы, указывая на различия. Я использую LINQ to SQL, который в вашем определении является просто стилем ORM Active-Record. Для меня это отлично работает, поскольку я работаю над множеством новых приложений и начинаю с базы данных, чтобы построить свои классы. Исходя из этого, я склоняюсь к тому, чтобы следовать подходу доменно-ориентированного дизайна (я знаю ... это первая концепция классов), работая с моими сгенерированными классами. Для меня это быстро помогает мне двигаться дальше.
Сказав это, я также работал с Entity Framework и NHybernate. Entity Framework - это преобразователь данных UBER, а NHybernate - также преобразователь данных, но без особой сложности! Я лично считаю, что Entity Framework предстоит пройти долгий путь. Если бы мне когда-либо понадобилось больше сложности, например, в приложении для старых объектов, где база данных была четко высечена, и мне нужно было, чтобы мои классы представляли мое приложение, а не мою базу данных, я бы предпочел перейти к чему-то более похожему на NHybernate и его функция отображения данных.
Я думаю, что каждый из этих инструментов имеет свое место. Было бы несправедливо утверждать, что все они такие же, как и они. Активная запись хороша тем, что она генерирует для меня классы, которые непосредственно представляют мою базу данных. Это работает, когда я создал базу данных или база данных точно представляет мои вездесущие термины и концепции приложения.
Дело не в том, что прямой SQL - это дьявол - иногда требуется написать необработанный SQL, чтобы запрос выполнялся так, как вы хотите. Для меня ORM - это скорее устранение ручной работы, чем что-либо еще (например, отказ от SQL любой ценой). Я просто не хочу настраивать все объекты моего кода на все вручную созданные запросы для каждого проекта. Это просто нелепый объем работы и мыслей. Вместо этого инструменты ORM предоставляют удобный и автоматизированный способ создания объектов данных, которые в противном случае потребовали бы много ручной работы. Теперь у меня могут быть автоматические объекты отдельных строк, для которых я могу расширять и создавать собственные функции, не задумываясь об этом. Я могу извлекать связанные строки из разных таблиц без необходимости вручную кодировать этот запрос.
Похоже, ваш пример класса User взят из phpDataMapper , и если да, то он также имеет некоторые другие встроенные тонкости, такие как автоматическая миграция таблиц, поэтому вам не нужно распространять файл SQL для вашего структуры таблиц, а также несколько вспомогательных функций и прочего. Все включенные функции призваны сэкономить ваше время - это основная цель.
Наиболее важное различие между AR и DM состоит в том, что строка ActiveRecord (AR) знает о собственном хранилище данных и, следовательно, имеет функции сохранения / обновления для каждой строки. объект - $ user-> save () - «Запись» является «активной». С другой стороны, с DataMapper (DM) каждая отдельная строка НЕ знает о собственном хранилище данных по определению. Строка - это скорее бессмысленный объект значения, с которым можно работать в вашем коде. Картограф отвечает за перевод изменений в этой строке обратно в хранилище данных - $ mapper-> save ($ user). Это самое существенное различие - вы обнаружите, что большинство основных функций ORM одинаковы практически в любой реализации. В основном это просто вопрос того, как это собрано на уровне ядра архитектуры.