ORM является все еще “Вьетнам Информатики”?

Да.

Объектно-ориентированный все еще объектно-ориентированы , и Реляционный все еще Ориентированы на набор . Ничто не изменилось в этих двух парадигмах за прошлые два года, чтобы заставить их работать лучше вместе.

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

Во всем программировании, существует компромисс между гибкость и предположения . Платформы (такие как направляющие) пытаются решить проблему, будучи "самоуверенными". Таким образом, они ограничивают гибкость или реляционного или объектно-ориентированных аспектов проблемы, делая предположения о том, как данные структурированы, и какие операции можно сделать с ним. Естественно, упрощение пространства задач делает решение более простым также.

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

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

я не думаю, что его сообщение приняло во внимание возможность самой платформы (в этом случае AcitveRecord/Rails) определение базы данных AND the Object Model, которая - насколько я могу сказать - заставляет проблему уйти.

, Так как это - противоположность первых двух ответов (в основном, что сообщение устарело), я чувствую, что, вероятно, не понимаю что-то; Если это так, исправьте меня вместо того, чтобы просто провалить меня, потому что я думаю, что существует важная суть, которую я упускаю.

Я могу только говорить за свой опыт. Я использую DAL и DTO, и я все еще способен к выполнению довольно сложных запросов (соединения и все), и также я в состоянии обратиться к или пользовательскому SQL SP каждый раз, когда мне нужно. Это сделало мою жизнь легче, мой код последовательный и мои крайние сроки более достижимый.

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

база данных А является обязательно низким уровнем; это хранит числа и строки по существу. Бизнес-логика является высоким уровнем. Поэтому у нас есть абстракция.

Лично, я думаю, что путем Rails/ActiveRecord является лучшее решение наличия объекта/модели предметной области, но также и способности использовать в своих интересах реляционную базу данных.

Так: не выводите ORM, но не принимайте значение по умолчанию к нему также. Это - инструмент, который решает определенные проблемы. Проигнорировать его было бы не осведомлено, и всегда использовать его будет высокомерно.

Многие компании Web 2.0 работают над хранилищами ключей. И все эти компании вынуждены проходить один и тот же мучительный процесс, чтобы заставить его работать.

Если ORM - это «вьетнамская компьютерная наука», то создание собственного хранилища значений ключей - это, вероятно, «Ирак компьютерной науки» :-)

Я думаю, что это делает.

Я думаю, что последнее предложение является самым интересным из всех: "Я склонен допускать ошибку на стороне лагеря базы данных поскольку модель, потому что я думаю, что объекты переоценены". Java, C++ и C# являются, конечно, доминантными языками, но функциональное программирование делает возвращение с F#, Scala, и т.д.

Раскрытие: я - автор RDO.Net.

Да. Я полагаю, что существующие ORMs входят в неправильное направление - они пытаются отобразить реляционные данные в произвольные объекты, которые, по моему скромному мнению, просто не возможны. В мире OO произвольный объект не является дружественной сериализацией/десериализацией, потому что каждый объект имеет ссылку на объект (адрес), который локален для текущего процесса. Хорошо, когда Вы будете иметь дело с отдельным объектом, Вы попадете в беду при направлении с диаграммой составного объекта.

, Надо надеяться, эта проблема может быть решена с помощью другого подхода, как в RDO.Net: вместо того, чтобы отобразить реляционные данные в произвольные объекты, мы отображаем схему данных как богатые метаданные (Model, который содержит столбцы, основные / внешние ключи, проверки, и т.д.), и представьте бетон Db, DbTable, DbQuery и DataSet для доступа к данным. При выполнении операций базы данных CRUD Вы создаете Абстрактное синтаксическое дерево (AST) SQL явно с помощью языка OO со строгим контролем типов, как продемонстрировано в следующем демонстрационном коде C#, который создает запрос и возвращает DataSet для иерархических данных:

public async Task<DataSet<SalesOrderInfo>> GetSalesOrderInfoAsync(_Int32 salesOrderID, CancellationToken ct = default(CancellationToken))
{
    var result = CreateQuery((DbQueryBuilder builder, SalesOrderInfo _) =>
    {
        builder.From(SalesOrderHeader, out var o)
            .LeftJoin(Customer, o.FK_Customer, out var c)
            .LeftJoin(Address, o.FK_ShipToAddress, out var shipTo)
            .LeftJoin(Address, o.FK_BillToAddress, out var billTo)
            .AutoSelect()
            .AutoSelect(c, _.Customer)
            .AutoSelect(shipTo, _.ShipToAddress)
            .AutoSelect(billTo, _.BillToAddress)
            .Where(o.SalesOrderID == salesOrderID);
    });

    await result.CreateChildAsync(_ => _.SalesOrderDetails, (DbQueryBuilder builder, SalesOrderInfoDetail _) =>
    {
        builder.From(SalesOrderDetail, out var d)
            .LeftJoin(Product, d.FK_Product, out var p)
            .AutoSelect()
            .AutoSelect(p, _.Product)
            .OrderBy(d.SalesOrderDetailID);
    }, ct);

    return await result.ToDataSetAsync(ct);
}