基于WPF mvvm的设计，大家看看怎么样

林小BA 2020-05-25 03:21:46

...全文

103 回复打赏收藏转发到动态举报

写回复

回复

切换为时间正序

请发表友善的回复…

发表回复

源码中基于GalaSoft.MvvmLight库搭建了MVVM设计框架，以及各个关键点的详细注释说明，望各位大牛多多指点！

算子全部是源码，带自定义UI WPF视觉软件源码，Halcon机器视觉和运动控制软件框架源码，WPF MVVM开发模式，1:1参考easyvision开发，集成几十个软件算子，纯源代码，上手可用。WPF MVVM开发模式，插件框架。注意：此版本以添加ui设计器。具体功能如上所示，可以自定义变量，写c#脚本，自定义流程，包含了halcon脚本和封装的算子，可自定义ui，通过插件形式开发很方便拓展自己的功能。详情可看博客 https://blog.csdn.net/weixin_44291381/article/details/135098693?csdn_share_tail=%7B%22type%22%3A%22blog%22%2C%22rType%22%3A%22article%22%2C%22rId%22%3A%22135098693%22%2C%22source%22%3A%22weixin_44291381%22%7D

一个WPF基于MVVM模型的简单抽奖程序，可以支持导入txt文档，适合初学wpf的同学看看哦

　　前段时间学习了一下Prism，感觉应该找个机会实践一下，而且前段时间，贱内(希望我老婆看不到这篇文章:))让我帮她做个定时提醒的小工具，做好之后感觉以前做了好多自己能用的小工具，如果能够整合到一起，该多好，所以，想起来做个个人工具集成平台，用来继承一系列我自己的以前做过的小软件。知识背景　　主要的知识背景是基于WPF的框架Prism，这个框架是微软的CodePlex中的一个Team开发的平台，现如今貌似已经发布4.0了。唉，说到这里，我以前的公司就是用的这个框架做的应用程序，现在的公司虽然比以前的公司待遇好了，不过用不着做WPF了，也基本上不使用任何框架开发，郁闷啊，呵呵，发发牢骚。在我的“个人平台”里面，没有使用整个框架，只是将框架减配加到我的基础类库里面。使用的东西包括，“Bootstrapper”，“ServiceLocator”，还有“Modularity”，而且我只是借用了他们的思想，然后进行了轻量级的实现。特别是其中的“Modularity”部分，我使用了微软推出的MEF架构进行了简单的实现，经过单元测试，效果不错。　　大家如果有兴趣研究Prism的知识，可以访问下面的链接：　　http://compositewpf.codeplex.com/ 　　应用程序的外壳使用WPF的应用程序，并且采用了MVVM模式，个人感觉这种方式更有利于子系统的集成。希望大家要是进行WPF的开发一定要关注这种模式，能够带来很多好处，比如：解耦、利于单元测试、界面利于更换等等。名词解释　　模块：　　实现应用程序（个人集成平台）功能的各个部分；　　子系统：　能够集成到应用程序（个人集成平台）中的各个功能插件；系统结构图1 Personal Integration Platform系统结构图　　(1). Personal.Component 　　作为基础模块，借助于Prism的思想，轻量级的实现了部分Prism的功能。包括Bootstrapper，ServiceLocator，以及Modularity（使用MEF架构）。　　(2). Personal.Presentation 　　作为基础模块，对WPF的MVVM模式进行了简单的支持。　　(3). IntegrationUtilities 　　对子系统集成的逻辑进行支持，在此模块中定义了集成的规范的数据结构，以及用于子系统集成的服务（服务的概念借助于Prism中的ServiceLocator）。　　(4). PersonalIntegrationPlatform 　　个人集成平台，这个也就是这个应用程序最核心的部分，整个应用程序的入口，外壳程序。　　(5). NotifyIconWpf 　　一个第三方的开源WPF控件，用过Winform的同志们都知道，NotifyIcon是个系统托盘。因为我希望的是，我的软件运行后直接运行在托盘中，而不是在桌面上占据个Form跑着，我觉得大家平时用软件，肯定没有那么多时间老是盯着一个Form在那里操作，因此，我觉得采用系统托盘的方式比较好，需要的时候打开，不需要的时候，就在系统托盘里面呆着。　　(6). Sub-System 　　子系统，可以有任何有.net知识的人员开发并且集成到平台中，只要符合集成平台的集成规范就可以。现在已经默认集成了ShutDown子系统，后续还会集成我原来做过的一些比较有用的小程序。呵呵，大家有兴趣，也可以按照继承规范，向里面集成一些自己喜欢的子系统。使用技术思想　　谈到技术思想，主要的思想其实就是面向对象，因为那几个所谓的SOLID思想都是由面向对象的思想衍生出来的。希望大家读到我的这篇文章，不能够奢望大家有收获，但是，希望大家能够不把注意力过于集中到使用的技术，或者编程的技巧，而是集中到系统的结构以及技术思想的运用上。也就是说，不在乎怎么实现，而是在乎怎么组织。嘿嘿，这样就是我为啥给大家看这个系统的结构图，而不是代码的原因，在后面会附上这个项目的源代码，如果对大家有用的话，大家可以拿去看看。集成方法　　(1). MEF框架　　MEF框架应该是微软在.net 4.0中推出的一种框架，我理解，主要就是运用IOC的思想进行解耦。最大的好处就是可扩展，这个思想其实早就有，想设计模式中的观察者模式，IOC/DI的思想，以及好莱坞原则，其实都是运用的这种松耦合，可扩展的模式设计的。所谓的松耦合，不是没有耦合，而是耦合到基础的框架，什么叫基础框架，就是谁都能耦合的框架，比如: 如果你写的是.net的应用程序，那你肯定要与.net进行耦合，所以解耦的概念是相对的，耦合才是绝对的。　　这里只是想为大家引入这个概念与这种思想，这里并不对MEF进行

项⽬重构⽅案设计项⽬重构⽅案设计近期接⼿到⼀个已经成型的项⽬，然后我们的任务就是对它进⾏重构，这个项⽬是⼀个功能⾮常齐全的WPF视频播放器（附带⾮常多其它功能），在细致研究了项⽬的背景和架构以后，初步做出了⼀下的重构⽅案：眼下现状：尽管整个系统做得⾮常美丽，代码也写得不错。但仍有下⾯不⾜： 1. 架构有待改善。尽管看似MVC架构，却没有遵循MVC的模式。⾥⾯逻辑和UI耦合⾮常⾼，没有清晰的规律。 2. 没有充分⽤到WPF的特性。WPF除了给我们⾮常多炫丽的效果外。还给我们提供了诸如Binding,command等特性，这些特性能够帮我们隔开耦合，同⼀时候降低代码量。 3. 代码和⽂件没有组织。代码、dll、样式⽂件和资源⽂件等没有统⼀的组织，到处都有。这样看起来就会⾮常混乱。 4. 没有建⽴公⽤代码库。没有把公⽤的代码库独⽴出来，⾮常多地⽅都是另外在写，这样既添加了代码量，同⼀时候维护和重构也带来了⿇烦。 5. 逻辑处理不应暴露在Client端。项⽬是⼀个C/S架构的系统。没有必要把全部的逻辑都暴露在Client端。应该⽤分布式把Logic放在server端。这样能够更安全同⼀时候使client变⼩。 6. 没有单元測试。这样⼀个庞⼤的程序，没有单元測试是⾮常危急的。我们不可能做到100%的覆盖率，可是我们能够对基本的逻辑和Function做单元測试。这样既降低了測试⼈员的⼯作量同⼀时候整个系统的安全、稳定和可维护性得到了⼤⼤的提⾼。 7. 性能不够优化。启动项⽬,通过WPF性能⼯具Perforator和Visual Profiler分析得出，程序启动和界⾯操作都导致CPU⾮常⾼。内存也消耗⽐較多。解决⽅式 1. 针对缺陷1的"架构问题"。做法是採⽤MVP或者MVVM模式。眼下正在对照和考虑。 2. 针对缺陷2的"WPF特性"。做法是充分利⽤Binding,command等特性。 3. 针对缺陷3的"代码和⽂件没有组织"。做法是建⽴⼀些单独的project或者⽂件来分类和组织这些代码，⽽且充分隔离耦合。 4. 针对缺陷4的"没有建⽴公⽤代码库"。做法是把⼀些公⽤的代码和经常使⽤的代码做成单独的Dll,⽽且有完整的单元測试，这样才⼲提⾼效率。 5. 针对缺陷5的"逻辑处理不应暴露在Client端"。做法是⽤WCF做为中间层。把业务逻辑所有进⾏封装。通过WCF提供统⼀的接⼝供项⽬调⽤。 6. 针对缺陷6的"没有单元測试"。做法是⽆论⽤MVP还是MVVM，我们起码保证对逻辑组件的代码有充分的单元測试覆盖，同⼀时候对⼀些公⽤的组件也要有单独的单元測试代码。 7. 针对缺陷7的"性能不够优化"。这个我会单独做⼀个性能优化列表出来，针对耗资源的操作和其它有损害性能的操作，我们应该避免。 8. 那么我们就能够结合实际情况搭建例如以下的结构 9. 10. 由于使⽤了MVVM模式，所以UI结构图就做例如以下调整 11. 12. 由于整个项⽬客户部希望我们引⽤第三⽅的组件或者⼯具。所以⾮常多功能都仅仅能通过企业库实现。⽐⽅AOP和IOC,log和exception对项⽬特征做了定制化，数据訪问通过企业库重写实现局部ORM,对性能要求⽐較⾼的应⽤仍然实现存储过程。对所有事务操作都转移到数据库。邮件使⽤JOB进⾏发送。⼤型数据和客户要求较⾼的实时操作。⽤MSMQ和SSB相结合的⽅式。层次依赖关系 UI: 功能模块使⽤时候,都会⾸先通过UI层次Security模块的安全验证(验证是通过Components模块⾥⾯的⾃⼰定义的⽤于页⾯功能以及功能点验证的控件触发), Security模块会通过服务层获取⽤户⾝份数据,⽤于页⾯验证. 功能模块的实际功能实现,假设须要数据库⽀持,那么依旧会通过服务层进⾏数据操作.整个架构基于MVVM模式。 Service:通过WCF做中间服务。使应⽤隔离开来，这样有利于扩展和维护。同事提⾼了整个应⽤程序的伸缩性。 Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调⽤,由上往下调⽤,逐级依赖,最后Service底层边界Data Access模块将调⽤Framework中的 Data模块,Data模块将调⽤MS.EntLib3中的Data,向数据server发送数据操作命令和数据. Framework: 该层次提供很多基础的功能模块（七⼤块）,分别提供给UI,Service层⾥⾯的模块直接或者间接的调⽤,同⼀时候也能够看到Framework层次内部各模块之间再执⾏时也有互相依赖调⽤的关系存在.该层次的部分模块会依赖和调⽤Ms.EntLib3中的模块,通常是依照两个层次⾥⾯的模块名称,产⽣关系的. MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的

3,405

社区成员

1,071

社区内容

发帖

与我相关

我的任务

社区管理员

加入社区

近7日
近30日
至今

加载中

查看更多榜单

社区公告

暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章