我在工作中遇到了以下问题，我没有经验或知识来回答这些问题，我希望你们中的一些明智的人能够为我指明正确的方向，任何答案将不胜感激！
Scenario
实施立面图案 http://en.wikipedia.org/wiki/Facade_pattern
外观基本上是复杂子系统的适配器。由于您有两个子系统，我建议创建三个具有以下功能的类：
HumanResourcesFacade：一个包含所有“人力资源”功能的类。此类的工作是公开执行人力资源应用程序负责的每个工作单元的方法，而不向客户端公开有关人力资源应用程序的任何信息。
HomecareFacade：一个包含所有“Homecare”功能的类。此类的工作是公开执行 Homecare 应用程序负责的每个工作单元的方法，而不向客户端公开有关 Homecare 数据库的任何信息。
ApplicationFacade：一个包含两者的类HumanResourcesFacade and HomecareFacade并向您的客户提供不需要了解两个嵌套外观的内部工作原理的公共方法。此类的工作是了解：(a) 两个嵌套 Facade 中的哪一个负责每个客户端调用，(b) 通过调用嵌套 Facade 上的适当方法来执行客户端对 ApplicationFacade 的调用，以及（ c) 将从嵌套外观接收的数据转换为客户端可用的格式，并且不依赖于任一嵌套外观的数据格式。
我建议使用 POCO 对象模型来创建不依赖于实际持久性实现的通用数据代码内表示。 Adrian K 建议的领域模型技术是一种很好的方法，但如果您不熟悉模式和方法，最终可能会变得非常混乱，并且比更直观的技术花费更长的时间。另一种方法是只使用数据对象和数据映射器。数据映射器基本上从数据源获取数据并将其转换为不依赖于数据源或映射器对象的对象。我在下面添加了一个链接。
我想澄清的一件事是，虽然我说ApplicationFacade有三份工作，我不建议你违反单一责任原则 http://en.wikipedia.org/wiki/Single_responsibility_principle。我的意思并不是说该类需要自己完成所有这三件事，而是说它应该封装您决定用于执行该过程的任何机制，并且应用程序的任何其他部分都不应从外部访问这些问题。ApplicationFacade。例如，您的业务对象不应该知道它们是从哪个数据源构建的 - 该信息不应该从除了由业务对象封装的内容之外的任何地方访问。ApplicationFacade class.
参考文章
- Martin Fowler 谈应用立面 http://martinfowler.com/apsupp/appfacades.pdf
- Martin Fowler 谈数据映射器 http://martinfowler.com/eaaCatalog/dataMapper.html
-
免费但全面的领域驱动设计介绍 http://www.infoq.com/minibooks/domain-driven-design-quickly
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
