在我的公司,我们开发了一些应用程序。我们必须为一个应用程序(比如应用程序A)创建一个API,以便其他应用程序可以使用它(一个its数据)。
问题是:我们已经为应用程序A的模型开发了PHP类,如果我们想要创建一个API,我们应该:
PHP
通常,API是第二种解决方案(与PHP一起使用,而不是作为web服务),但我发现我们做了一个复杂而有用的类建模,然后为了拥有函数、字符串和数组而拆分它,这太糟糕了。在我看来,第三个是折衷方案,但我的一位同事坚持认为这不是一个API。太糟糕了..。
你觉得呢?
发布于 2010-02-18 16:48:33
从架构的角度来看,3号解决方案可能是最好的。基本上,您是在使用Facade Design Pattern来简化您的应用编程接口。因为我现在正在处理它:在Patterns Of Enterprise Application Architecture中,这种方法被描述为service layer,这是完全有意义的,因为你不想让任何用户(即处理你的应用程序接口的人)暴露于比实际需要或期望的更复杂的情况下。
这包括使用尽可能简单的接口和传输对象(原始值,如果它们有意义)。一旦您的外观通过远程服务(如webservice)被调用,您最终将不得不将响应和请求分解为原始值(数据容器)。
发布于 2010-02-18 16:29:41
构建一组用于简化公共API的外观类。
发布于 2010-02-18 18:15:13
创建一些薄包装器,在原始类上实现更简单的API。不要在包装器中重新实现任何业务逻辑-如果任何逻辑发生更改,这都会给您带来麻烦,因为您肯定会忘记哪些部分被修改了,哪些没有被修改。保持外部输入/输出简单,如果你需要比字符串更复杂的东西,对结构化数据使用XML或JSON,但尽量避免太复杂-如果你有两件事要传递,两个查询参数可能比一个有两个字段的结构要好得多。
这就是“门面”模式。
https://stackoverflow.com/questions/2290202
复制相似问题