Я думаю, что вы правы. В моем текущем задании (веб-разработка) каждый отдельный доступ к базе данных реализован как сервис. Мы "ЧИСТАЯ СОА", как сказал ведущий архитектор ... Ух ты!
На самом деле, это добавляет много сложности всему. Когда я хочу прочитать содержимое простой таблицы, я должен сгенерировать что-то вроде 8 проектов, 42 файлов, 8 сборок и, возможно, 9 файлов конфигурации!
Большая сложность, как я уже сказал. Скорее всего, кто-то где-то забудет один файл ... Выставлять простой процесс как услугу глупо.
В моих книгах вы должны представлять свои процессы как сервис, когда:
- Многие приложения, использующие разные языки и фреймворки, должны вызывать ваши вещи.
- Вовлечено более одной платформы (Windows, Unix ...).
- Обрабатываемые данные являются ядром предприятия.
Кроме того, обратите внимание, что служба должна быть ПРОЕКТИРОВАНА, чтобы быть службой, и что разработка службы по крайней мере так же сложна, как и разработка библиотеки: перехват ошибок должен быть тщательно продуман, ведение журнала должно быть достаточно гибким, документация должна быть полной и т.д.
Ну, как я вижу, большинство услуг, которыми я пользуюсь ежедневно, не будут использоваться другими людьми: нет документации, плохая обработка ошибок, частые изменения кода, данные второй зоны ...
Ну очень интересный вопрос. 1 балл: о)