Каковы преимущества и недостатки использования сервисов перед компонентами?

Question

В последние несколько месяцев я работаю над проектами в новейших платформах dot net.

Мне кажется, что в последних версиях dot net "услуги" поощряются поверх компонентов. Это правильно?

Я видел в серебряном свете (я новичок в серебряном свете), все операции слоя DB выставляются как сервисы. Я не знаю, сейчас компонентные программы также доступны?

В чем преимущества? А как насчет производительности, если все уровни представлены как сервисы вместо DLLS?

Пожалуйста, пролите свет на эту тему: где мне начать понимать эту концепцию правильно?

Спасибо

SC

Answer 1

Это действительно все, что связано с сервис-ориентированной архитектурой - что-то, что было распространено некоторое время и очень популярно.

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

Скажем, у вас был компонент проверки кредитной карты. Вы можете написать этот код и скомпилировать его в DLL и начать включать его во все ваши приложения. Ничего плохого в этом нет, если только вы не заметите ошибку или правила проверки CC изменятся. Или, может быть, вы хотите обновить его, чтобы проверить его в черном списке. Вы не можете делать ничего из этого, не перекомпилировав приложения, которые его используют.

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

Другое преимущество использования сервисов перед компонентами заключается в том, что сервисы могут быть размещены где угодно. Они могут быть на локальном сервере или на другом конце света.

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

Answer 2

Что еще нужно учитывать - просто потому, что функциональность предоставляется как «служба», не означает, что она должна быть размещена где-то или представлена ​​как веб-служба.

Вы можете легко получить доступ к услуге напрямую, в памяти.

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

Answer 3

Совместимость с другими языками - еще одно преимущество. Вы можете написать сервис на C # .net, к которому также можно получить доступ из Java. Таким образом, повторное использование выходит за рамки использования языка программирования.

В чем преимущества? Что насчет производительность, если все слои выставлены как сервисы вместо DLLS?

Я бы обратил внимание на этот момент здесь. Что вы подразумеваете под "всеми слоями"? Уровни приложений, такие как бизнес и уровень доступа к данным Я сомневаюсь, что это может быть полезно (конечно, это зависит от вашего контекста), но обычно сервис - это то, что может быть повторно использовано во многих различных контекстах. Примером может служить сервис для проверки фискального кода. Затем вы вызываете эту услугу из бизнес-уровня вашего приложения. Я не могу представить случай, когда вы бы представили бизнес-уровень как отдельный сервис, а уровень доступа к данным - как отдельный. Обычно они весьма специфичны для вашего приложения, которое вы разрабатываете. Возможно, у вас есть приложение, которое, например, доступно через Интернет (как веб-приложение), и есть еще одна точка входа через веб-сервис, который могут использовать другие приложения (какой-то API). Это имело бы смысл, однако вы не будете напрямую выставлять свой бизнес-уровень, а просто создадите своего рода «шлюз», которым является ваш веб-сервис (легкий фасад, который делегирует вашим классам бизнес-логики).