ORM и SOA в мире .NET

Question

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

Answer 7

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

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

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