Question

我有一个与某个BPM供应商合作的内部企业应用程序（EJB2）。内部应用程序的当前实现涉及引入仅由供应商的API公开的对象，并通过API中的公开方法对其进行更改。

我在想我需要以某种方式将内部对象映射到这个外部对象，但这看起来太简单了，我不太确定这样做的最佳策略。任何人都可以了解他们过去如何处理这种情况吗？

我想要“黑盒子”这个供应商的软件，所以如果需要我可以轻松更换它。从设计的角度来看，以某种方式将内部对象映射到此公开的API对象的最佳方法是什么？请记住，我的内部应用程序仍然需要与API通信，因此两者之间会有一些依赖关系，但我想减少它，所以我也可以使用junit从这个软件中单独测试。

谢谢，杰森

Answer 1

为服务层创建一个接口，在内部所有代码都可以使用它。然后创建一个使用该接口的类并调用第三方api方法并作为api facade。

即

interface IAPIEndpoint {
    MyDomainDataEntity getData();
}

class MyAPIEndpoint : IAPIEndpoint {

    public MyDomainDataEntity getData() {
        MyDomainDataEntity dataEntity = new MyDomainDataEntity();
        // Call the third party api and fill it
        return dataEntity;
    }
}

将第三方api连接起来总是一个好主意，这样你就不会让他们放弃你的app域，你可以根据需要换掉它们。您可以创建另一个完全使用不同服务的类实现。

要在代码中使用它，只需调用

即可

IAPIEndpoint endpoint = new MyAPIEndpoint(); // or get it specific to the lang you are using.

当跨越多个实现时，基于接口制作你的东西是要走的路。它也适用于TDD，所以你可以将界面换成本地测试，可以检查你的域代码完全独立于第三方api。

Answer 2

抽象;实现一个DAL，它将提供从内部到外部和后面的过渡。

然后，如果您切换供应商，您的内部结构仍然有价值，您可以更改供应商特定的代码;假设供应商提供相同的功能和相互关联的数据类型。

Answer 3

我将成为这里的黑羊并倡导YAGNI原则。问题是如果你现在做一个抽象层，它看起来会非常接近第三方API，它只是一个冗余层。由于您现在不知道假设的未来第二个供应商的API会是什么样的，您不知道需要考虑哪些差异，并且任何未来的端口都可能需要对那些无法预料的差异进行返工。

如果您需要测试框架，我建议您使用与BPM供应商相同的API进行自己的测试实施。更好的是，几乎所有信誉良好的API提供商都提供某种沙箱模式进行测试。如果他们不这样做，你应该要求一个。

需要帮助改善紧密耦合的设计

3 个答案: