最佳asp.net WCF应用程序设计
我正在使用一个金融应用程序，并正在寻找设计我的应用程序的最佳解决方案。
我们有 100 个存储过程，其中包含我们的大部分/所有业务逻辑。我们有使用 Web 服务软件工厂 (http://servicefactory.codeplex.com/) 构建的 WCF Web 服务项目。我们为几乎所有内容（表、下拉列表等）构建了存储过程，并且每个存储过程都有自己的 Web 服务可供 Web 应用程序调用。每个 Web 服务都是一个非常简单的方法，它使用 Web 服务的确切参数调用存储过程。
我不太确定这是否是最好的设计，想询问设计的建议和替代方案。
还有人有类似的环境吗？您这边是如何实施的？
I am working with a financial application and am looking for the best solution for designing my application.
We have 100's of stored procedures where most/all of our business logic sits. We have WCF web services projects built using Web Service Software Factory (http://servicefactory.codeplex.com/). We have stored procedures built for nearly everything (tables, dropdowns, etc..) and each of these stored procs have their own webservice exposed to be called by the web application. Each web service is a very simple method that calls the stored procedure with the exact paramaters of the web service.
I am not too sure if this is the best design and would like to ask for suggestions and alternatives to the design.
Does anyone else have a similar environment ? How is it implemented on your end ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是一个典型的权衡：
。一般来说，我想说我更喜欢方法#1 - 保持你的服务美观、小且易于维护，并尊重单一职责原则 - 服务（或类）应该只做一件事，而且只做一件事。
您也许可以将逻辑上属于一起的几个调用组合到一个具有几个调用的服务中 - 但是一旦该服务有太多调用（超过 10？15？20？），它就会变得笨拙并且你最终不得不频繁地改变它，因为它处理太多的任务......
It's a classic trade-off between:
In general, I would say I would prefer approach #1 - keep your services nice and small and easy to maintain, and respect the single responsibility principle - a service (or class) should do one thing and one thing only.
You might be able to combine a few calls that logically belong together into a single service with a few calls - but as soon as the service has too many calls (more than 10? 15? 20?) it has a tendency to get unwieldy and you end up having to change it too frequently because it handles so many tasks....
我的看法基于服务的预期用途 - 它们是要为外部应用程序提供服务还是仅用于您的应用程序内的使用？
对于应用程序内的使用，我倾向于使用进程内的闲聊层，而不是进程外层（例如，执行 CRUD 任务的服务层等）。前者从性能角度来看非常好，并且通过使用多个 Web 服务器等仍然可以进行扩展。相同的进程内层可以托管在多个前端 - 例如用于应用程序 UI 的 Web 应用程序、执行日常工作的控制台应用程序、WCF第三方使用的服务等。事务管理和流动上下文信息在进程内层中可以很简单 - 尽管可以在 WCF 服务层中实现 - 但它非常昂贵。
对于外部消费者来说，WCF 服务是很好的前端，但服务接口应该是块状的，并且必须严格从业务术语公开功能（例如，它不应该具有用于持久性的 CRUD 方法，而应该具有从域中有意义的方法 - 例如 CreateOrder这将在多个表中创建条目）。
My take is based on what is intended use of services - are they going to server external applications or meant for consumption within your application only?
For within-application usage, I tend to go with an in-process chatty layer rather than having an out of process tier (for example, services layer doing CRUD tasks etc). Former are very good from performance perspective and scaling can be still possible by using multiple web servers etc. The same in-process layer can be hosted with multiple fronts - for example a Web app used for Application UI, Console App doing daily job, WCF services consumed by third party etc. Transaction management and flowing contextual information can be simple in in-process layer - although its possible with WCF Services layer - its very expensive.
For external consumers, WCF services are great front but then service interface should be chunky and must expose functionality strictly from business terms (for example, it should not have CRUD methods that are meant for persistence but rather methods that make sense from domain - say CreateOrder that would create entries into multiple tables).