1

我们目前正在审查如何将我们的核心业务组件（在代码中）与前端开发隔离开来。我们已经有了多层架构，但它们是使用 dll（或某些地方的 web 服务）引用的。

我们想做的是将部分 UI 外包给外部开发人员。问题是我们必须提供可以逆向工程的dll，然后才能“获得”核心业务逻辑代码。

解决此问题的一种方法不是使用 dll 公开 BO，而是使用 Webservices 公开 BO。然而，问题很少。例如安全性、调试、异常处理、托管等。对我来说，这听起来不适合上面提到的问题，但 Web 服务也不适用于此类问题。

我想知道有没有人遇到过类似的情况？或者如果有人这样做了？如果是这样怎么办？

谢谢，

4

3 回答 3

1

接口契约的概念在这里似乎很贴切。

如果您的接口的契约定义良好（让它们成为 DLL 入口点、WSDL 等等），那么创建一个允许 UI 开发人员测试行为的模拟实现应该不会很困难。

我们采取的唯一预防措施是要求 UI 承包商将代码提交到我们的 SVN 存储库（不，这里没有 Git :)），以便我们的构建机器可以连续运行集成测试，并且我们可以每天评估进度和问题。

于 2012-10-16T15:37:50.450 回答
1

提供实现业务逻辑的 Web 服务点 - 这将由您自己托管并可供 UI 开发人员访问。

通过这种方式，您可以控制业务逻辑，并且 UI 团队可以访问 API。

如果这不可行，请将您的业务逻辑的公共接口提取到它自己的包中，并实现一组“罐装”响应——只是供 UI 人员使用的硬编码数据。这允许您为 UI 团队提供他们将集成的界面以及示例数据，但无需您的实际业务逻辑。

于 2012-10-16T08:39:06.393 回答
-1

y 原则可能会帮助您分离您所要求的关注点。

它是一种系统地分离业务和技术关注点的方法。

以下字符图形描述了该方法：

  Business requirements      Technical requirements
+------   |                             |  ------+
|         v                             v        |
|  Business model               Technical model  |
\          \                            /      /
 \          \                        /       /
   \          \                    /       /
     \          > Mapping rules <        /
       \              |                /
         \            |              /
          \           v             /
           \    Implementation     /
            \         |           /
             \        |          /
              \       v         /
               Acceptance Tests

如果映射规则一致并且可以重复应用，则该方法可以自动化。反向 y 分析可以显示是否是这种情况。

如果该方法适用，它将对效率产生深远影响。无需一遍又一遍地将业务问题映射到技术问题，该过程可以重复并最终实现自动化。

您可以在我的公司网页上找到更多信息。

于 2012-10-16T13:02:18.483 回答