开发者

Why limit WCF ServiceContracts to 10-20 OperationContracts?

开发者 https://www.devze.com 2022-12-23 19:18 出处:网络
I\'ve seen recommendations (Juval Lowy, et al) that a service contract should have \"no more than 20 members...twelve is probably the practical limit\". Why? It seems 开发者_运维百科that if you wish t

I've seen recommendations (Juval Lowy, et al) that a service contract should have "no more than 20 members...twelve is probably the practical limit". Why? It seems 开发者_运维百科that if you wish to provide a service as the interface to a relatively large db (50-100 tables) you're going to go way past that in just CRUD alone. I've worked with plenty of other services that provided hundreds of 'OperationContracts'...is there something peculiar about WCF? Is there something I'm missing here?


probably the fact that you should not expose CRUD in the SOA world.... the idea is to expose business processes. Inidividual CRUD operations lead to a TERIIBLY slow and granular interface. Look more how RIA Services / ASTORIA do the CRUD thing.

I don tthink this is a technical limit. the idea is a service defines all contracts necessary for a business operation (order management, account management) and should not be TOO complicated.


I think it's related to the principles of SOA. Many people would regard a service with hundreds of OperationContracts as a poorly designed service, even if technically correct.

You should not simply expose a web interface for a bunch of tables. Rather, the services should expose abstract operations (probably mapped to business processes) that interact with those tables under the hood.


I've seen similar recommendations in the past and I think it depends on who's going to use your service. If, like me, you're writing it to link an app to a remote data source then the most abstract interface you can write will still include a "get" and a "save" method for each logical object in your database. My latest project has a servicecontract with 246 operation contracts in it. It's a mostrosity of a file and a pig to edit, but the client side code is neat and tidy and it's just easier to work with. It's not like anyone but me is ever going to see it.

In short, there are no technical or performance implications to either approach. Go with whatever seems most appropriate to your project.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号