设计具有表示层和基于Web服务的API的系统
我们正在设计一个系统，其function在表示层和公开的API层基本相同。 我的问题是使用什么技术/策略，以便我们可以在考虑性能的情况下从代码中获得最多的重用？
这是一个简化的例子：
用户可以通过Web表单添加客户 。 这将触发Customer.Create（）方法。
API使用者/用户可以通过SOAP / HTTP-POST将客户添加到将调用Customer.Create（）方法的Web服务。
想象一下这些层：
PRESENTATION | | WEB SERVICE API (Customer.Create() is available here | | FACADE Business Object Interface - Customer.Create() signature is here | | BUSINESS Business object - Customer.Create method() is fleshed out here | | DATA ACCESS - Writes data 表示层SOAP调用Create（）Web方法，该方法调用Facade的Create（）方法，该方法调用业务对象的Create（）方法，该方法通过数据访问层连接。
问题：
是否关注在表示层中使用API的Web服务的性能，或者是否有将表示层直接连接到外观的替代方法？ 如果是这样，使用什么技术（WCF，远程处理，Web服务等）？
如果您需要更多说明，请与我们联系。 我很难发现在表示层中使用API是否很常见，或者出于性能原因“绕过它”。
我可能没有看到任何其他问题？
谢谢！
看看这个问题和答案（一个我的）：
WCF和n层架构和序列化性能
我认为你的等级很好，如果它们都是合乎逻辑的，虽然我个人不会使用Facade，而是我会使用ORM来连接数据库。
关于技术，WCF和ASP.NET MVC是比Web服务更好的选择，现在它已经过时而且效率低下。 远程处理由WCF取代，现在不应该使用。
您的Web服务API和外观是多余的。 我在想如果你在每一层中实现实际的对象，我想你会发现这两层对象中的一个或另一个只是传递对象。
像CreateCustomer（）这样简单的业务层对象看起来似乎也是多余的，但对于更复杂的函数，您会发现业务层在一个事务下带来了几个primefaces调用。