0

我正在使用金融应用程序，并正在寻找设计我的应用程序的最佳解决方案。

我们有 100 个存储过程，我们的大部分/所有业务逻辑都位于其中。我们有使用 Web 服务软件工厂 (http://servicefactory.codeplex.com/) 构建的 WCF Web 服务项目。我们已经为几乎所有东西（表格、下拉菜单等）构建了存储过程，并且每个存储过程都有自己的 web 服务，可以被 web 应用程序调用。每个 Web 服务都是一个非常简单的方法，它使用 Web 服务的确切参数调用存储过程。

我不太确定这是否是最好的设计，并且想寻求设计的建议和替代方案。

其他人有类似的环境吗？它是如何在你端实施的？

4

2 回答 2

2

这是一个经典的权衡：

  • 拥有只做一件事且只做一件事的小型、专注的服务——你最终会得到很多
  • 拥有更大的服务，有很多方法可以做很多事情——但你的服务更少

一般来说，我会说我更喜欢方法#1——让你的服务保持良好、小巧且易于维护，并尊重单一职责原则——服务（或类）应该只做一件事和一件事。

您也许可以将逻辑上属于一起的几个调用与几个调用组合成一个服务 - 但是一旦服务有太多调用（超过 10 个？15 个？20 个？），它就会变得笨拙和您最终不得不过于频繁地更改它，因为它处理了很多任务......

于 2010-10-04T05:14:34.337 回答
1

我的看法是基于服务的预期用途——它们是用于服务器外部应用程序还是仅用于在您的应用程序中使用？

对于应用程序内的使用，我倾向于使用进程内聊天层而不是进程外层（例如，执行 CRUD 任务的服务层等）。从性能的角度来看，前者非常好，并且仍然可以通过使用多个 Web 服务器等进行扩展。可以使用多个前端托管相同的进程内层 - 例如用于应用程序 UI 的 Web 应用程序、用于日常工作的控制台应用程序、WCF第三方使用的服务等。事务管理和流动的上下文信息在进程内层可以很简单 - 尽管它可能与 WCF 服务层 - 它非常昂贵。

对于外部消费者来说，WCF 服务是很好的前端，但是服务接口应该很粗大，并且必须严格从业务术语中公开功能（例如，它不应该具有用于​​持久性的 CRUD 方法，而应该具有从域中有意义的方法 - 例如 CreateOrder这将在多个表中创建条目）。

于 2010-10-04T06:05:10.263 回答