ORM и SOA в мире .NET

По моему опыту основные рамки ORM для .NET(NHibernate, LinqToSql, Entity Framework) работают лучше всего, когда отслеживают загруженные объекты. Это отлично подходит для простых клиент-серверных приложений, но при использовании архитектуры с тремя или более уровнями с веб-сервисами в сервис-ориентированной архитектуре это невозможно. В конце концов, написав много кода, чтобы сделать отслеживание самостоятельно, это можно сделать, но не ORM должен упростить доступ к БД?

Является ли идея использовать ORM в сервис-ориентированной архитектуре вообще?

Ответ 1

LLBLGen Pro имеет отслеживание изменений внутри объектов. Это означает, что вы можете получить граф из базы данных с использованием путей предварительной выборки (так что один запрос на граф node) и сериализовать его по проводу к клиенту, изменить его там, отправить обратно и напрямую сохранить график, как все отслеживание изменений находится внутри сущностей (и сериализуется внутри XML как компактные пользовательские элементы).

Отказ от ответственности: я ведущий разработчик llblgen pro.

Ответ 2

Это зависит от того, что вы подразумеваете под "SOA". Выявление объектов домена в контрактах на обслуживание редко является хорошим дизайном обслуживания - оно раскрывает детали внутренней реализации, существует большая вероятность изменения опубликованного контракта, а управление версиями становится очень трудным.

Если вы создаете собственные документы сообщений (например, WCF DataContracts) для своих конечных точек обслуживания, относительно просто использовать ORM для реализации службы. Как правило, вы перезагрузите объект домена из базы данных и измените свойства карты (или вызовите метод), а затем сохраните изменения.

Если ваш сервис - это в основном методы CRUD, ваше пользовательское сообщение будет эффективно DTO. Вам нужно будет вручную управлять оптимистичным concurrency и отображением объектов домена.

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

Ответ 3

Взгляните на описание предстоящих синхронизаций и отключенных наборов в DataObjects.Net

Ответ 4

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

Если вам не нравятся накладные расходы на передачу данных в сообщениях и из них, я бы предложил вам посмотреть REST. Однако не REST в том, как это делают службы ADO.NET Data, это просто распределенные объекты по HTTP.

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

Ответ 5

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

Ответ 6

SignumFramework имеет отслеживание внутри объектов. У него также есть полный поставщик Linq, но он работает только с новыми базами данных (он генерирует схему из ваших объектов С#, а не oposite).

Отслеживание изменений: http://www.signumframework.com/ChangeTracking.ashx

Отказ от ответственности: я ведущий разработчик Signum Framework:)

Ответ 7

Вы можете использовать memcached как кеш второго уровня с NHibernate - это то, что вы имели в виду под "Отслеживание"?