我用相似的标题查看了没有成功的问题。我可以从业务层创建服务引用以从其他业务实体提取数据吗?还是应该从服务层完成?业务层与服务层的服务引用
回答
这并不容易回答,因为它可能会成为一个巨大的哲学讨论。但是,我认为您的业务逻辑层不应该返回到您的服务层以获取其他业务实体。
此场景的典型方法是在业务逻辑之上有一个Facade层。当需要检索多个商业实体时,该层负责协调响应。所以:
服务 - >业务外观 - >业务逻辑 - >数据
编辑:对于小型,简单的应用程序,这是矫枉过正。删除外观层,并简单地让服务调用一个逻辑方法,或让服务调用多个逻辑方法。
服务层实际上只是一个传递,你最好用尽可能少的逻辑。这使得可以替换服务层,或者在不需要进行服务调用时让受信任的应用程序/服务直接(在本地计算机上)调用Facade层。
此方法还允许您在门面级别放置“信任线”,并在此处实施安全性。如果要进行安全检查,并且可能还有其他事情在这个“信任线”上,那么我们只需要一个服务调用到商业门面,所以我们不会为每个需要检索的实体重复这个逻辑。
外观层只是调用逻辑层上的方法的一层方法。 Facade方法可以像调用逻辑层上的一个方法一样简单,而且它们可以像调用逻辑层上的多个方法一样复杂,并协调合适的域实体甚至DTO的一致响应。
我可以继续。确实有很多专门讨论这个问题的书。希望这至少有助于广泛的概述。
所以鲍勃你在说不!到业务层的服务引用?在这种情况下,你是否建议将商业门面的VS项目分开? (它与服务层分开)。 –
正确。希望您的业务层在安全机器上运行,并且客户端代码不会直接调用它们。客户端代码会调用服务层,服务层会调用业务外观等等。一个单独的项目通常是要走的路,但这取决于所有这些是多大。对于大型应用程序,是的,使用一个单独的项目。 –
好的,谢谢! –
- 1. n层业务/服务层设计
- 2. 具有n层业务服务器的N层Web服务器
- 3. Windows服务与服务层
- 4. 服务层和Web API服务层?
- 5. 将业务层传递给WCF服务
- 6. struts动作类和业务服务层
- 7. 服务和服务层
- 8. 服务层模式:跨越多个服务的业务逻辑
- 9. 从服务层
- 10. Python服务层
- 11. 可以在业务层对象“服务”一个DAO层对象?
- 12. 业务层错误和服务层处理 - 最佳方式?
- 13. 服务层=应用层= GRASP控制层
- 14. 管理层vs服务层
- 15. jalo层vs服务层
- 16. 与服务API层和CRM
- 17. 将服务层与验证层分开
- 18. 业务层中的Web引用或服务引用,其中是发布的url?
- 19. 映射与服务层或业务逻辑位置
- 20. 控制器逻辑与服务/业务层逻辑
- 21. 业务层3
- 22. 服务层建议
- 23. AutoMapper在服务层
- 24. C#,GenericRepository,服务层
- 25. WPF MVVM服务层
- 26. ZF1 Doctrine2服务层
- 27. 又该服务层
- 28. 服务层验证
- 29. 访问服务层
- 30. Asp.Net Mvc服务层
谢谢Bob!刚刚为以前的问题做过...... –