locked
mvvm的总结和困惑,有人能回答我的两个问题吗? RRS feed

  • Question

  • 美好的定义
    View 视图
    1.视图是一个视觉元素,如窗口,页面,用户控件或数据模板。视图定义中包含的观点和视觉布局和样式的控制。
    2.通过其DataContext的属性视图模型视图引用。控制在视图中的数据绑定到视图模型所暴露的属性和命令。
    3.该视图可以自定义视图和视图模型之间的数据绑定行为。例如,视图可以使用值转换器,以在UI中显示的数据进行格式化,或它可以用于提供附加的输入数据验证用户的验证规则。
    4.视图定义和处理UI视觉行为,如动画或转换可能引发从视图模型的状态变化,或通过用户的交互与UI。
    5.视图的代码隐藏定义UI逻辑来实现可视化的行为,是很难在XAML中表达或要求直接引用特定的UI控制在视图中定义。
    ViewModel 视图模型
    1.视图模型是一个非可视类,不从任何WPF或Silverlight基地的类派生。它封装了支持用例或用户在应用程序中的任务所需的表示逻辑。视图模型可测试的独立的视图和模型。
    2.视图模型通常不直接引用视图。实现该视图数据绑定的属性和命令。通知视图通过更改通知事件通过作INotifyPropertyChanged和了InotifyCollectionChanged的的接口的任何状态变化。
    3.视图模型坐标模型视图的互动。它可以转换或数据进行操作,以便它可以很容易地消耗的视图,并且可以实现额外的特性,可能不会出现在该模型。它也可以实现IDataErrorInfo进行InotifyDataErrorInfo接口接口通过数据验证。
    4.视图模型可能定义逻辑状态视图可以直观地表示给用户。
    Model  模型
    1.模型类非视听类应用程序的数据和业务逻辑封装。他们负责管理应用程序的数据和封装所需的业务规则和数据验证逻辑,以确保其一致性和有效性。
    2.模型类不直接引用视图或查看模型类,并具有不依赖于它们是如何实现。
    3.模型类通常通过作INotifyPropertyChanged和了InotifyCollectionChanged的的接口提供财产和集合更改通知事件。这让他们可以很容易地在视图中的数据绑定。模型对象的集合类,代表通常从的ObservableCollection <T>的类派生。
    4.模型类通常提供数据验证和错误报告通过IDataErrorInfo进行InotifyDataErrorInfo接口的接口。
    5.模型类通常用于与服务或信息库,它封装了数据访问和缓存结合。
    Business 业务
    1.业务类进行逻辑处理,反应整个应用程序的业务处理办法,按照职能对方法和操作进行分类。
    2.业务类不依赖任何数据持久化技术。
    4.业务类遵循类的设计原则,单一职责原则,开放封闭原则,替换原则,依赖倒置原则,接口隔离原则。
    Communication 通讯
    1.通讯类定义通讯的数据结构和标准。
    2.通讯类定义通讯调用方法名称,参数和返回结果。
    3.通讯类实现单向或双向的数据通讯。
    Data 数据
    1.数据类实现Business需要的持久化要求。
    2.数据类只关注数据存储技术,可以是任何数据存储方式只要能满足性能需求和存储需求。
    3.数据类根据依赖倒置原则依赖于Business满足Business的需要。

    现实的问题

    验证在哪里执行。
    办法一 验证在ViewModel实现 InotifyDataErrorInfo View层能够很好的体现验证。
    Model怎么办 Business 不需要验证输入吗?
    1.Business无法保证传入的Model已经在ViewModel 或者 Mvc中的Controller 做过验证?
    2.输入的Model是否正确变成别人说的算也就是ViewModel或者Controller相对与Business层风险很大。

    办法二 Model层实现 InotifyDataErrorInfo
    1.View层如何表现Model的验证?难道用ViewModel在实现InotifyDataErrorInfo 并调用Model的InotifyDataErrorInfo?这个是可以实现,是否有多余的代码?
    2.Model实现了 InotifyDataErrorInfo 是否可以用于传输。
    3.Model实现了 InotifyDataErrorInfo 在其他模式MVC MVP 中是否能够被持续重用重用的办法是什么?

    办法三 直接在View实现验证
    这个办法可能是最愚蠢的办法,但是它是否是现实中最容易修改和创作的办法?
    比如我封装一个MoneyInput通过MaxValue(最大值) MinValue(最小值) Accuracy(精度)等可以很容易封装和验证用户的输入。虽然最终我会有很多控件比如AgeInput,DatetimeInput,SexInput等等但是这个结构很容易重用最少在表现层是这样的。

    通讯层和业务层相等吗?
    WCF通过增加Attribute(属性)标记属性和类就能够使一个Model同时兼容Contract(协议)的职责,看上去好像很美好也好像能够实现,那么Business和Communication能够合并吗?
    如果重新在对Communication进行定义是否是无谓的重复?很多方法名,类名,类属性完全相等至少99%我觉得。分离带来了复杂性的臭味。
    Wednesday, August 28, 2013 3:32 AM