Архитектура SOA для ASP.NET с Entity Framework - PullRequest
Новая
       2

Архитектура SOA для ASP.NET с Entity Framework

1 голос
/ 01 апреля 2011

Я перерабатываю архитектуру решения для реализации SOA .

После внесения изменений в конструкцию я придумал:

  • MySolution.Client.MyProject.Web ...... //ASP.NET WebSite
  • MySolution.Client.MyProject.Proxy .... // Проект библиотеки прокси-сервера службы C # * 1
  • MySolution.Service ........................ //Service.cs для Service.svc здесь
  • MySolution.Service.DataContract ...... //IService.cs для Service.cs здесь * [2]
  • MySolution.Service.HttpHost .......... //Service.svc здесь
  • MySolution.Model ..................... // Здесь представлены все пользовательские классы данных и модель EDMX * [3]
  • MySolution.Repository ................ // Репозиторий запрашивает БД с помощью запросов LINQ и ADO.NET

* 1 MySolution.Client.MyProject.Proxy: Этот проект содержит сервисный прокси и содержит классы презентаций

* [2] MySolution.Service.DataContract:

  • Этот проект содержит IService и классы запросов / ответов
  • Все методы в Service.cs принимают классы Request в качестве входных и возвращают классы Response в качестве выходных
  • Поэтому на этот проект ссылаются 2 клиентских проекта (веб и прокси-сервер), поскольку он содержит IService и все классы запросов / ответов, которые потребуются для связи с Service.cs

* [3] MySolution.Model: Этот проект содержит файл .edmx, представляющий собой модель данных Entity Framework, и некоторые пользовательские классы, используемые в проекте.

ПРОБЛЕМА:

Поскольку я использую только классы запросов / ответов для связи между службой и клиентом, проект MySolution.Service.DataContract используется только Service.cs и Repository.cs

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

Например:

  • Service.cs
  • Метод GetCustomer () в хранилище выполняет запрос LINQ и возвращает объект «Клиент»
  • Service.cs затем сопоставляет все свойства объекта «Клиент» с объектом «КлиентResponse»
  • Service.cs затем возвращает «CustomerResponse» вызывающей стороне.

В этом случае большинство свойств будет повторяться в обоих классах. Если есть решение, это хорошо, в противном случае, я в порядке.

Однако при вызове метода Repository.cs GetCustomers () ( Обратите внимание, что это не GetCustomer () ), он вернет список объектов Customer, и отображение этого для целей возврата будет означать "для цикл ", который повторяет коллекцию и выполняет сопоставление ... Это НЕ О'КЕЙНО ...

Есть ли лучший способ сделать это, учитывая, что я не хочу возвращать объект "Customer" без "CustomerResponse", так как, во-первых, это нарушает архитектуру SOA, и, во-вторых, я не хочу, чтобы мои клиентские проекты имели какие-либо ссылка на модель или репозиторий проектов?

Ответы [ 3 ]

2 голосов
/ 01 апреля 2011

Значит, у вас просто проблемы с отображением?Если это так, вы можете взглянуть на некоторые библиотеки отображения с открытым исходным кодом, такие как Mapper Extensions или AutoMapper , которые автоматизируют задачу.

1 голос
/ 01 апреля 2011

Если вам не нравится отдельное сопоставление между сущностями и DTO, укажите IQueryable в вашем хранилище и используйте прямые проекции для DTO. Недостатком является то, что такое решение не может быть эффективно проверено модулем. В таком сценарии имитация репозитория не имеет смысла, потому что макет запроса к запросу - это Linq-to-objects, тогда как запрос к реальному репозиторию - это Linq-to-entity (другой набор функций, где различие можно увидеть только во время выполнения).

Btw. Я не вижу слишком много SOA в вашем приложении - я вижу только многоуровневое приложение. Это как посадить дерево в саду и сказать, что у тебя есть лес. Более того, звучит так, будто вы создаете интерфейс CRUD (сущности почти от 1: 1 до DTO). У меня плохое предчувствие, что вы вкладываете слишком большие усилия в архитектуру, которая вам не нужна. Если ваше основное намерение состоит в том, чтобы строить операции CRUD, представленные в виде сервисов поверх базы данных, вы можете напрямую представлять объекты, более того, вы можете использовать такие инструменты, как Службы данных WCF .

1 голос
/ 01 апреля 2011

Похоже, вашей главной проблемой является утомительное сопоставление объектов данных с объектами передачи данных (DTO).Я сам этим не пользовался, но похоже, что AutoMapper создан для декларативного автоматического сопоставления объектов.

Я бы определенно придерживался того, чтобы ваши объекты данных были отделены отданные контракты в ваших услугах.

...