在《领域驱动设计》这本书里面，列举了三种可将业务逻辑建模为软件模型的模式，也就是大家常听说的事务脚本、贫血模型、DDD。有好些名字来描述这三种模式。...我们使用对象建模，就是把业务逻辑建模为 数据变化，然后把数据的改变和改变数据的行为放一起，数据变化，以及生命周期变化是业务的核心逻辑。 这个原因不得不回顾下面向对象的发展历史。...对UI的简单改动就会改变业务逻辑。改变业务规则可能需要小心翼翼地跟踪UI代码、数据库代码或者其他的程序元素。实现一致的模型驱动对象变得不切实际，而且自动化测试也难以使用。...面向对象还是默认的最优模型构建方式吗？ 这是一个有意思的问题，我也从没有思考过。 当前DDD还是很火热的，大家都在追求充血模型。...经过这几种风格对比，随着AI的兴起，还会再出现新的模型方法，将来OO还是追求的最优解吗？ 总结 实现业务架构的三种方式，贫血模型随处可见，而事务脚本与充血模型倒却难得一见。
背景 这里还有往下的一步就是如何把这个业务模型配置到工具中去。这个步骤其实在我写第二个专栏的时候，在第6章的最后是写了具体的操作过程的。...但是随着在群里、私信里、企业内训里被问到过多次这个知识点，我才发现，绝大部分的性能测试工程师，并不清楚统计出的业务模型如何具体配置到压力工具中，从而导致了容量场景的结果和统计出的业务比例模型并不一致。...甚至大部分人，都不会把容量场景结果中的业务比例模型和统计出的业务比例模型做比对。...所以，这次我就把这个问题从前到后说明白。 系统架构 因为业务模型中的比例对应的请求数经常是很多人困惑的重点，所以这里我要先把调用路径列清楚。 我们先来说一个最为直观的系统调用逻辑。...业务模型 有了架构，就得有具体的业务模型了。在这里我们设计一些比例关系。在这里，我先列出业务级的接口和相应的比例来。
不要把业务逻辑比如数据库操作相关的业务放在 Activities 或 Fragments 中。...ViewModel ViewModel 就像 View 和业务逻辑之间的粘合剂，它负责从 Repository 获取数据并提供给 View。...Model Model 就是你放置所有特定业务代码的地方，虽然从技术上讲，ViewModel 和 Model 之间存在一个以 Repository 形式存在的中间步骤，你可以将 Repository 中的所有内容视为远离用户界面的一组类...它负责从本地数据库或网络中获取数据并操作应用中的数据。 Repository 具有本地存储和服务器之间的中介这么一个特殊角色，你可以在此检查是否应该在本地缓存远程数据等。...，它并不关心这些 —— 这是 Repository 应该处理的业务逻辑。
( 摘自 维基百科-MVC ) 模型(Model) 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。...为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。 视图(View) 能够实现数据有目的的显示。...在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型(Model)，因此应该事先在被它监视的数据那里注册。...而ViewModel充当了一个UI适配器的角色，也就是说View中每个UI元素都应该在ViewModel找到与之对应的属性。...除此之外，从Controller抽离出来的与UI有关的逻辑都放在了ViewModel中，这样就减轻了Controller的负担。
( 摘自 维基百科-MVC ) 模型(Model) 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。...为了实现这种机制，那些用于监视此 Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变。 视图(View) 能够实现数据有目的的显示。...在 View 中一般没有程序上的逻辑。为了实现 View 上的刷新功能，View 需要访问它监视的数据模型(Model)，因此应该事先在被它监视的数据那里注册。...而ViewModel充当了一个UI适配器的角色，也就是说View中每个UI元素都应该在ViewModel找到与之对应的属性。...除此之外，从Controller抽离出来的与UI有关的逻辑都放在了ViewModel中，这样就减轻了Controller的负担。 ?
1）、如果需要实现多数据库支持。我想业务系统能够从sqlserver向oracle数据迁移，或反之。 这样在现有的项目结构方式，就无法满足，但是我们可以增加新的接口层来实现这个要求。...2）、如果我要求业务逻辑层实现也不一定固定，例如在医疗行业的话，每个医院的业务系统或业务流程都不相同，那么假设我们希望沟通统一的UI界面，而不是随着业务逻辑的改变而修改UI，那么我们就需要进行如下的设计...在原来的基础上改进： ThreeArchitecture.BLL.Interface：定义业务逻辑接口，主要目标是隔离UI与业务逻辑实现间的依赖关系，将实现代码调用修改为接口调用方式。...3、降低业务逻辑层与UI层的依赖，业务逻辑接口或实现的变化不会影像UI层。4、降低UI层调用的请求次 数及数据往返。...关于上面介绍的只写架构模式，我已经全部实现，如果需要相关的技术支持，请找我，或者您有什么建议或意见，都请联系我。
我只是想说说我们究竟应该如何理解 M-V-VM，当我们真正开始写代码时，应该在里面的每一层里写些什么。 ---- MVVM，当然三层——M-V-VM。...MVVM 只是数据驱动型 GUI 程序建议的开发模式；无论是三层中的哪一层，本质上都是在解决 UI 问题。 而非 UI 问题根本就不在 MVVM 的讨论之列。...不知看到这里时你会不会喷我一脸——“V”解决 UI 问题也就算了，“VM”和“M”算什么 UI！ VM，视图模型。其本质是模型。什么的模型？“视图”的模型。这是为真实的 UI 做的一层抽象模型。...MVVM 模式按此理解后，我们将更能够将代码放到合适的位置，避免 VM 代码的膨胀： 公共的控件或者辅助代码应该抽出来放到别处，比如形成公共组件 一些非 UI 的业务功能单独做，独立于 MVVM 模式，...创建多个 View 的时候，这些 View 能够完全一致而不用把此前逻辑再跑一边 无论如何都不能引用 View，就算是接口也不行 注意不要去调用一些单例类或者带状态的静态类，这样才好进行单元测试 Model
- Controller/Presenter/ViewModel（控制器/展示器/视图模型） 它是 Model 和 View 之间的胶水或者说是中间人。...二、MVP“架构” MVC的缺点在于并没有区分`业务逻辑和业务展示`, 这对单元测试很不友好. MVP针对以上缺点做了优化, 它将业务逻辑和业务展示也做了一层隔离, 对应的就变成了MVCP....P层处理完了业务逻辑，如果要更改view的显示，那么可以通过回调来实现，这样可以减轻耦合，同时可以单独测试P层的业务逻辑。...和MVP中负责业务逻辑的Presenter不同，VIPER的Presenter的主要工作是在View和Interactor之间传递事件， 并管理一些View的展示逻辑，主要的业务逻辑实现代码都放在了Interactor...MVVM和MVP的关系 而 MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
通常包含视图的状态、命令和数据模型的转换。ViewModel会响应View的命令，操作Model更新数据，然后将更新的数据显示到View上。...MVVM的关键优点在于提供了一个清晰的分层架构，这不仅有助于保持代码的组织和可维护性，还促进了UI和业务逻辑的分离，使得开发人员可以独立工作于视图或逻辑的开发上，从而提高了开发效率和降低了维护成本。...作为Model和View之间的中介，处理视图逻辑 D. 直接操作数据库或数据源 在MVVM模式中，Model是负责： A. 数据的展示 B. 用户界面交互 C. 业务逻辑处理和数据管理 D....促进了UI和业务逻辑的分离，提高了代码的可维护性 D. 增加了应用程序的响应时间 在MVVM架构中，如何实现数据的双向绑定？ A. 通过View直接修改Model B....MVVM架构的主要优点之一是促进了UI和业务逻辑的分离，提高了代码的可维护性。这种分离使得开发者可以更加专注于业务逻辑或UI设计，而不是两者之间的交互。 答案：B。
- 使用MVVM会轻微的增加代码量，但总体上减少了代码的复杂性。 MVVM 的注意事项 - viewController 尽量不涉及业务逻辑，让 viewModel 去做这些事情。...ReactiveCocoa或RXSwift通过这两个框架可以实现ViewModel和View的双向绑定， 但同样会存在几个比较重大的问题。...在工作中如果遇到量级非常重的控制器，可以针对实际的业务，将一组业务逻辑相关的代码抽取到一个独立的视图模型中处理。你可用子viewModel 来代表屏幕上更小的、更潜在的被封装的部分。...* ViewModel - 存放各种业务逻辑和网络请求，不能存在 UIKit 有关的东西。...在日常开发中，ViewModel是为了拆分Controller业务逻辑而存在的， 所以ViewModel需要提供公共的服务接口，以便为Controller提供数据。
mvvm是一种设计思想，是Model-View-ViewModel的缩写，本质上是MVC的改进版，即模型-视图-视图模型。Model指的是后端传递的数据。View指的是所看到的页面。...即模型-视图-控制器。M和V指的意思和MVVM中的M和V意思一样。C即Controller指的是页面业务逻辑。使用MVC的目的就是将M和V的代码分离。‘MVC是单向通信。...MVC和MVVM的区别并不是VM完全取代了C，ViewModel存在目的在于抽离Controller中展示的业务逻辑，而不是替代Controller，其它视图操作业务等还是应该放在Controller中实现...也就是说MVVM实现的是业务逻辑组件的重用。由于mvc出现的时间比较早，前端并不那么成熟，很多业务逻辑也是在后端实现，所以前端并没有真正意义上的MVC模式。...可重用性你可以把一些视图逻辑放在一个Model里面，让很多View重用这段视图逻辑。 3.独立开发。开发人员可以专注于业务逻辑和数据的开发(ViewModel)，设计人员可以专注于页面设计。
Model: 模型（用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法） View: 视图（渲染页面） Controller: 控制器（M和V之间的连接器，用于控制应用程序的流程，及页面的业务逻辑...MVC模式的特点在于实现关注点分离，即应用程序中的数据模型与业务和展示逻辑解耦。...图解 总结 首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。...Model 做沟通，而 View 可以透过一些机制 (例如: Events，Databindings…) 来和 ViewModel 沟通以取得数据或将数据抛给 Model 做存取等工作，ViewModel...最后我想提的是，MVC 的包容度比 MVVM 和 MVP 要来的高，在 MVC 的 V 层，可以再进一步的包含 MVVM 或 MVP 的实作，而 C 层也可以使用 MVP (V 是输出的资料) 来进一步切割数据的流动与输出
应用层、业务逻辑层及数据访问层。mvc的思想其实也一样，都是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。...相关View层交互触发及数据展示逻辑都在Activity中进行编码。 模型层(Model) 我们通常针对业务数据，都会定义好对应的Model层。...数据库的操作、对网络等的操作都应该在Model里面处理，当然对业务计算等操作也是必须放在的该层的 所以一直以来我们使用Android默认的项目结构开发，主要都是在采用mvc的架构思想。...mvvm MVVM可以算是MVP的升级版，其中的VM是ViewModel的缩写，ViewModel可以理解成是View的数据模型和Presenter的合体，ViewModel和View之间的交互通过Data...View（视图层）采用XML文件进行界面的描述； Model（模型层）通过网络和本地数据库获取视图层所需数据； ViewModel（视图-模型层）负责View和Model之间的通信，以此分离视图和数据。
当然这些事ViewModel已经帮我们做了，它可以取出 Model 的数据同时帮忙处理View中由于需要展示内容而涉及的业务逻辑。...MVVM有助于将图形用户界面的开发与business logic(业务逻辑)或后端逻辑（数据模型）的开发分离开来，这是通过置标语言或GUI代码实现的。...(2)Controller接收到指令之后，先完成所需要的业务逻辑，然后要求Model根据业务逻辑改变状态； (3)Model将新的数据发送给View，View则根据新的数据更新视图，从而用户的请求得到反馈...它是将数据模型双向绑定的思想作为变革的核心，即View的变动，自动反映在ViewModel上面，而ViewModel的变动也会随即反映在View上面，从而实现数据与模型的双向绑定。...的事件并格式化数据，不负责控制应用的状态； ViewModel 用于封装业务逻辑层，这点类似于 MVC 模式中的控制器，它控制View的很多显示逻辑，它可以把数据模型的变化传递给视图，也可以把视图中数据的变化传递给数据模型
领域驱动设计DDD（Domain Driven Design）提出了从业务设计到代码实现一致性的要求，不再对分析模型和实现模型进行区分。...l服务用于表示不是实体或值对象的自然部分的操作或活动。 领域模型在实现时可大可小，在业务的早期，在系统比较小的情况下，它有可能是一个类。当系统做大了以后，它可能是个库。...将领域服务（未附加到集合或实体的服务）与独立的微服务相匹配。 每个微服务应处理一个完整的业务功能。 领域模型又可以分为失血、贫血和充血3种。...充血模型：充血模型跟贫血模型差不多，不同的是如何划分业务逻辑，就是说，约大部分业务应该放到domain object里面，而service应该是很薄的一层。...核心实体（Entity）和值对象（Value Object）应该在Domain层，定义的领域服务（Domain Service）在Service Layer，而针对实体和值对象的存储和查询逻辑都应该在Repositories
模型负责管理应用程序的数据和业务逻辑，视图负责展示数据（UI界面），控制器负责接收用户输入并调用模型和视图完成用户请求。...缺点：数据绑定的复杂性可能导致性能问题，ViewModel 的设计和实现较为复杂。 1.2 通俗讲解 好的，我来用最简单的方式来解释这三种架构模式的区别：MVC、MVP和MVVM。...MVVM（模型-视图-视图模型） 模型（Model）：同MVC和MVP，负责存储数据和业务逻辑。...视图模型（ViewModel）：它是视图的抽象，负责处理视图的逻辑和数据。它使得模型中的数据更易于管理和使用。...总的来说，MVC、MVP和MVVM都是帮助开发者以一种更组织化的方式开发应用程序，它们之间的区别主要在于处理用户界面逻辑和后端数据逻辑的方式上。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
