Разработка системы с использованием уровня представления и API на основе веб-службы - PullRequest
Новая
       22

Разработка системы с использованием уровня представления и API на основе веб-службы

1 голос
/ 19 октября 2010

Мы разрабатываем систему, функциональность которой практически одинакова на уровне представления и на уровне API. Мой вопрос заключается в том, какую технику / стратегию использовать, чтобы мы могли максимально эффективно использовать наш код с учетом производительности?

Вот упрощенный пример:

Пользователь может добавить Клиента через веб-форму. Это вызовет метод Customer.Create ().

Потребитель / пользователь API может добавить Customer через SOAP / HTTP-POST к веб-службе, которая вызовет метод Customer.Create ().

Представьте себе эти слои: 

PRESENTATION
|
|
WEB SERVICE API (Customer.Create() is available here
|
|
FACADE Business Object Interface - Customer.Create() signature is here
|
|
BUSINESS Business object - Customer.Create method() is fleshed out here
|
|
DATA ACCESS - Writes data

Уровень представления SOAP вызывает веб-метод Create (), который вызывает метод Create () фасада, который вызывает метод Create () бизнес-объекта, который подключается через слой доступа к данным.

Вопросы:

Есть ли проблемы с производительностью при использовании веб-сервисов API на нашем уровне представления или есть альтернативы для подключения уровня представления непосредственно к фасаду? Если да, какую технологию использовать (WCF, Remoting, веб-сервисы и т. Д.)?

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

Какие-нибудь другие проблемы, которые я, возможно, не вижу?

Спасибо!

Ответы [ 2 ]

2 голосов
/ 19 октября 2010

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

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

1 голос
/ 19 октября 2010

Посмотрите на этот вопрос и ответы на него (один мой):

WCF и n-уровневая архитектура и производительность сериализации

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

Что касается технологий, то WCF и ASP.NET MVC являются гораздо лучшим выбором по сравнению с веб-сервисами, которые в настоящее время устарели и неэффективны. Удаленное взаимодействие было заменено WCF и никогда не должно использоваться сейчас.

...