Зачем ограничивать сервисные контракты WCF 10-20 операционными контрактами?

Question

Я видел рекомендации (Джувал Лоуи и др.), Что контракт на обслуживание должен иметь «не более 20 членов ... двенадцать, вероятно, практический предел». Зачем? Похоже, что если вы хотите предоставить сервис в качестве интерфейса к относительно большому дБ (50-100 таблиц), вам придется пройти мимо этого только в одном CRUD. Я работал с множеством других сервисов, которые предоставили сотни «OperationContracts» ... есть ли что-то особенное в WCF? Я что-то упускаю здесь?

Answer 1

вероятно тот факт, что вы не должны выставлять CRUD в мире SOA .... идея состоит в том, чтобы выставлять бизнес-процессы. Отдельные операции CRUD приводят к МЕДЛЕННО медленному и детальному интерфейсу. Посмотрите больше, как RIA Services / ASTORIA делают CRUD.

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

Answer 2

Я думаю, что это связано с принципами SOA.Многие люди считают услугу с сотнями OperationContracts плохо разработанной, даже если она технически исправна.

Вы не должны просто выставлять веб-интерфейс для нескольких таблиц.Скорее, сервисы должны предоставлять абстрактные операции (вероятно, сопоставленные с бизнес-процессами), которые взаимодействуют с этими таблицами под капотом.

Answer 3

Я видел подобные рекомендации в прошлом, и я думаю, что это зависит от того, кто собирается использовать ваш сервис. Если, как и я, вы пишете его, чтобы связать приложение с удаленным источником данных, то самый абстрактный интерфейс, который вы можете написать, будет по-прежнему включать метод «get» и «save» для каждого логического объекта в вашей базе данных. Мой последний проект имеет контракт на обслуживание с 246 контрактами на эксплуатацию. Это большая часть файла и кода для редактирования, но код на стороне клиента аккуратен и аккуратен, с ним просто работать. Это не похоже ни на кого, кроме меня, когда-нибудь это увидят.

Короче говоря, нет никаких технических или эксплуатационных последствий для любого подхода. Пойдите с тем, что кажется наиболее подходящим для вашего проекта.