我与财务应用程序的工作，我期待为我的设计应用的最佳解决方案。最佳asp.net WCF应用设计
我们的大多数/所有的业务逻辑位于存储过程100的。我们有使用Web服务软件工厂（http://servicefactory.codeplex.com/）构建的WCF Web服务项目。我们已经为几乎所有东西（表格，下拉等等）构建了存储过程，并且这些存储过程中的每一个都有自己的Web服务，这些Web服务暴露给Web应用程序调用。每个Web服务都是一个非常简单的方法，它使用Web服务的确切参数调用存储过程。
我也不太清楚，如果这是最好的设计和想问的建议和方案的设计。
别人也有类似的环境？它是如何实现你的目的？
这之间的经典折衷：具有体积小，集中服务，做一两件事，一件事只有
一般来说，我会说我宁愿方法＃1 - 保持你的服务好，小，易于维护，并尊重单一责任原则 - 一服务（或课堂）应该做一件事，一件事只有东西。
您可能可以将几个逻辑上属于同一个服务的呼叫合并成一个服务，但只要有太多的呼叫（超过10？15？20？），它就有一个趋势让笨拙，最终不得不因为它处理这么多的任务，去改变它过于频繁....
我的看法是基于什么打算使用的服务 - 他们打算服务器外部应用程序或意味着消费仅在您的应用程序中？
对于内的应用程序的使用，我倾向于去有一个进程健谈层，而不是一个彻头彻尾的过程层（例如，服务层做CRUD任务等）。从性能角度来看，前者是非常好的，并且通过使用多个Web服务器等仍然可以进行扩展。同一个进程内层可以托管多个前端 - 例如用于应用程序UI的Web应用程序，执行日常工作的控制台应用程序WCF第三方消费的服务等等。事务管理和流动的上下文信息在进程内层可以很简单 - 虽然它可能与WCF服务层一起使用，但它非常昂贵。
对于外部消费者来说，WCF服务非常重要，但是服务接口应该是笨重的，并且必须严格按照商业术语公开功能（例如，它不应该有用于持久性的CRUD方法，而应该包含从域 - 说CreateOrder，将创建条目到多个表）。