Дизайн программного обеспечения и дизайн веб-сервисов

Question

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

Теперь вопрос заключается в том, должен ли я создать 1 единственный метод и использовать их повторнодля веб-приложения и веб-службы API?(Это кажется логичным решением, однако оно очень сложное; гораздо проще дублировать метод, используемый веб-приложением, и хранить оба отдельных, то есть один метод для веб-приложения и один метод для веб-службы.)

Как вы, ребята, делаете это?

1) REUSE: один основной метод и повторное использование их как для веб-приложения, так и для приложения веб-службы (мне нравится это, но это сложно)

• WebAppMethodX --uses -> COMMONFUNCTIONMETHOD_X
• APIMethodX --- использует ----> COMMONFUNCTIONMETHOD_X

т.е. Commonfunctionmethod_x содержит многократно используемый набор общих функций

PRO: меньше кода, меньше обслуживания, меньше ошибок.

CON: очень сложно

2) ДУБЛИКАТ: два метода, один метод для веб-приложения и один метод для веб-службы.

• WebAppMethodX
• APIMethodX

PRO: просто

CON: дублирование = больше кода, больше обслуживания, больше ошибок!

Answer 1

Ваш вариант использования, скорее всего, будет отличаться для вашего общедоступного API веб-сервиса от вашего внутреннего API приложения.Создайте общий сервисный проект / уровень и используйте этот же уровень как из своего веб-приложения, так и из общедоступного API веб-сервиса.Создайте отдельный метод http-invokable для каждого вашего веб-приложения и веб-службы.

Все сводится к

1) различным проблемам безопасности.Например, неплохо (часто требуется) предоставить пример клиентского приложения, использующего ваш публичный API, чтобы другие могли легко освоиться с тем, что вы предоставили.Этот клиентский API может нуждаться в передаче предоставленных вами объектных конструкций, лишенных внутренней, защищенной логики / содержимого.(Помните, что скомпилированный C # также может быть открытым текстом с помощью Reflector!)

2) различные потребности и ограничения.Например, для внутреннего вызова приложения вы будете иногда приводить в исполнение другие бизнес-правила по сравнению с вашим общедоступным API веб-сервиса (часто с последним гораздо более ограниченным по объему).

Если вы разрабатываете свою бизнес-логикув ваш сервисный уровень и хорошо вызывайте эти классы / методы из вашего веб-проекта и вашего проекта веб-сервиса, соответственно, вы все равно будете иметь многократное повторное использование кода, не пытаясь усложнить вещи, смешивая варианты использования.

Answer 2

Один метод. В противном случае, когда вы найдете ошибку и исправите ее в одном, а затем забудете в другом ... вы будете плакать.

Answer 3

Один метод в веб-сервисе, и ваше веб-приложение вызывает его.

Я не понимаю, что означает "один основной метод" для обоих. У веб-приложений нет основного метода; они развернуты на сервере приложений.

Еще один момент, на который следует обратить внимание: вы должны написать свой сервис в терминах интерфейса POCO. После этого развертывание становится выбором, который вы делаете.

Answer 4

Это зависит ..

Обычно я бы их отделил.Таким образом вы удаляете взаимозависимость между двумя процессами высокого уровня.Повторное использование кода хорошо в процессе, но иногда вы хотите иметь возможность использовать другое приложение в той же службе.

Если они сильно зависят друг от друга, однако, вы захотите повторно использовать одни и те же функции, чтобы изменение их в одном месте изменило их в другом.Таким образом, избежать более потенциальных проблем с процессом разработки.