http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc.xsd"> <!-- 把后面的3.x去掉 --> ——————— 作者：大道至简_lyon 来源：CSDN 原文：https://blog.csdn.net/a5601564/article/details/51585232 版权声明：本文为博主原创文章，转载请附上博文链接！
View DetailsMVC I’m dating with a model… and a view, and a controller. 众所周知，MVC 是开发客户端最经典的设计模式，iOS 开发也不例外，但是 MVC 有让人无法忽视的严重问题。 MVC, short for Massive View Controller 在通常的开发中，除了简单的 Model、View 以外的所有部分都被放在了 Controller 里面。Controller 负责显示界面、响应用户的操作、网络请求以及与 Model 交互。这就导致了 Controller： 逻辑复杂，难以维护。 和 View 紧耦合，无法测试。 于是微软的大牛提出了 MVVM Model View ViewModel 既然 View 和 Controller 是一对好基友，在 MVVM 里面，干脆把它们当做 View。 现在将原来 Controller 的部分职责拆分出来由 View Model 承担，主要包括： 校验用户输入。 网络请求。 展示层的逻辑，比如格式化字符串。 其他不能放入 Model，与 View 无关的逻辑。 原来的 Controller 现在只负责绑定 View 和 ViewModel。值得注意的是，View Model 不包含与 View 直接关联的部分。一般来说，只要代码中没有#import <UIKit/UIKit.h>即可。 MVVM 的优点 MVVM 兼容 MVC，可以先创建一个简单的 View Model，再慢慢迁移。 MVVM 使得 app 更容易测试，因为 View Model 部分不涉及 […]
View Details领域模型 领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系。 业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业务用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。 贫血模型是指领域对象里只有get和set方法（POJO），所有的业务逻辑都不包含在内而是放在Business Logic层。 优点是系统的层次结构清楚，各层之间单向依赖，Client->（Business Facade）->Business Logic->Data Access Object。可见，领域对象几乎只作传输介质之用，不会影响到层次的划分。 该模型的缺点是不够面向对象，领域对象只是作为保存状态或者传递状态使用，它是没有生命的，只有数据没有行为的对象不是真正的对象，在Business Logic里面处理所有的业务逻辑，对于细粒度的逻辑处理，通过增加一层Facade达到门面包装的效果。 在使用Spring的时候，通常暗示着你使用了贫血模型，我们把Domain类用来单纯地存储数据，Spring管不着这些类的注入和管理，Spring关心的逻辑层（比如单例的被池化了的Business Logic层）可以被设计成singleton的bean。 假使我们这里逆天而行，硬要在Domain类中提供业务逻辑方法，那么我们在使用Spring构造这样的数据bean的时候就遇到许多麻烦，比如：bean之间的引用，可能引起大范围的bean之间的嵌套构造器的调用。 贫血模型实施的最大难度在于如何梳理好Business Logic层内部的划分关系，由于该层会比较庞大，边界不易控制，内部的各个模块之间的依赖关系不易管理，可以考虑这样这样的实现思路： （1）铺设扁平的原子业务逻辑层，即简单的CRUD操作（含批量数据操作）； （2）特定业务清晰的逻辑通过Facade层来组装原子操作实现。 （3）给业务逻辑层实施模块划分，保持模块之间的松耦合的关系。 举例说明： 原子业务逻辑层（Service）提供了用户模型的条件查询方法： List<User> queryUser(Condition con) Facade层则提供了一种特定的业务场景的分子接口，满足18岁的中国公民，内部实现调用的正是上述的原子接口： List<User> queryAdultChinese() Facade、Service层纵向划分为几个大的领域包：用户、内容和产品。 充血模型层次结构和上面的差不多，不过大多业务逻辑和持久化放在Domain Object里面，Business Logic只是简单封装部分业务逻辑以及控制事务、权限等，这样层次结构就变成Client->（Business Facade）->Business Logic->Domain Object->Data Access Object。 它的优点是面向对象，Business Logic符合单一职责，不像在贫血模型里面那样包含所有的业务逻辑太过沉重。 缺点是如何划分业务逻辑，什么样的逻辑应该放在Domain Object中，什么样的业务逻辑应该放在Business Logic中，这是很含糊的。即使划分好了业务逻辑，由于分散在Business Logic和Domain Object层中，不能更好的分模块开发。熟悉业务逻辑的开发人员需要渗透到Domain Logic中去，而在Domian Logic又包含了持久化，对于开发者来说这十分混乱。 其次，如果Business Logic要控制事务并且为上层提供一个统一的服务调用入口点，它就必须把在Domain Logic里实现的业务逻辑全部重新包装一遍，完全属于重复劳动。 使用RoR开发时， 每一个领域模型对象都可以具备自己的基础业务方法，通常满足充血模型的特征。充血模型更加适合较复杂业务逻辑的设计开发。 充血模型的层次和模块的划分是一门学问，对开发人员要求亦较高，可以考虑定义这样的一些规则： （1）事务控制不要放在领域模型的对象中实现，可以放在facade中完成。 （2）领域模型对象中只保留该模型驱动的一般方法，对于业务特征明显的特异场景方法调用放在facade中完成 from:https://www.cnblogs.com/zjoch/p/4435549.html
View Details