探讨关于程序开发的设计模式

Question

目前我做的程序就是一个工程，编译出来就是一个exe文件，文件体积不仅大也不易于维护升级。于是想到了模块化设计。
但是由于以前没有做过Winform程序，所以对如何合理地设计不是很清楚，所以希望有经验的朋友能够给予指点。
我想把自己做的理财软件重新按最优的方式改造，如果有朋友看过我的东西，请结合这个Case进行讲解。
1、怎样分模块才算合理？
2、具体开发中怎么引用？
3、还有什么好的设计模式可以借鉴？

Answer 1

要空谈太容易了，什么三层啊，表现层，业务层，数据层什么的，表现层用MVC什么的>>>理财软件但还是具体点好，你的程序都涉及些什么？跟数据库有关么？参考下面一书里的架构
Application Architecture for .NET: Designing Applications and Services
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

Answer 2

To saucer:感谢您的指教。
那我就具体地谈吧，以我自己的软件做案例：个人理财（下载http://work.ahfun.net/soft.asp?softid=44）。
主要实现的是个人收支状况的记录。用的是access数据库，目前功能算是完成了，我也从一个初学者对VB.Net有了一定的了解，但是自己对程序的设计还是不满意，所以希望能得到高手的指点。
我想把整个程序用标准的设计方法重新开发。

Answer 3

可以根据系统的功能，划分出多个独立的模块，每个模块生成一个dll,然后有一个主程序，来引用各个dll,一般升级的时候只要重新覆盖相应的dll或是exe就可以了对设计模式不是很懂，就随便说说自己的想法了，希望不要误导别人

Answer 4

很简单呀。你根据业务不同，划分成N个模块，分别编译成DLL不就行了？

Answer 5

Night_Elf(风暴虫) ( )说的对！

Answer 6

我说一点自己的小经验吧，我是写小程序的。希望对你能多少有点启发。最简单的原则：界面逻辑和业务逻辑分离。这说起来容易，做起来可能很郁闷，关键是一个分离的“度”，也就是说究竟界面做什么、业务做什么。一般来说，即面逻辑管界面的事，可以用一个Form类来实现。诸如“某些情况下这个菜单项要变灰”的事情都交给界面做。但是如何让界面知道该这么做，不应该是让你的后台去调用Form改变它的状态，应该是后台提供一个用于查询状态的方法，让界面来调用，通过得到的状态，界面自己来改变自己的显示。然后，后台除了处理相关的事物外，应该提供一组方法用于响应界面传过来的事件。比如我的后台支持搜索，那么我应该在这个类中提供DoSearch()方法，在界面的按钮单击事件中，我只要调用这个方法（当然还包括从文本框获取参数等事情，这些都可以由界面来完成）。上面只是最简单的情况——只有两个类，界面（继承自Form）和后台。当然对于复杂的程序基本也就是这样，只不过需要一些其他的类来辅助，比如需要一个Drawer来辅助Form进行绘图的工作，或者可以把后台中复杂且庞大的算法单独封装为一个类。但是至于Dll这种东西应该理智地考虑，能不用则不用。最后，上面提到了很细微的一点，也是最重要的，即“调用方向”，也就是说永远是界面去调用后台，如果后台发生什么事情希望界面能改变，那么请使用事件或委托，不要在界面里提供方法让后台来调用。这样做的好处是，你可以随意更改界面。比如可以将后台单独做成一个Dll，而界面不再是WinForm，而是WebForm，你就得到了一个Asp.NET应用。再进一步，你把后台的每个公共方法标记为“WebMethod”，你就得到了一个Web Services，其他人基于你的这个Web Services可以随意地开发，WinForm应用也行，ASP.NET应用也行，甚至J2EE都行。——这话说远了，不好意思。近点来说，如果你（或你的客户）觉得界面不够美观，或操作不方便，你可能就要对界面动个大手术，这时如果你保证调用方向是单项的，你就可以只修改界面，无须改动后台。如果你的后台有问题，你只要保证后台提供和界面交互的方法，则也可以随意修改。——但记住，也不要想用接口来实现。---
本来想说点有用的，结果还是变成了瞎白乎，希望能有点启发吧……我写程序也是很烂的……

Answer 7

to  楼主：
    winform的程序几乎没有做过。所以不是很了解。做的web方面的程序到是比较多。在web方面一般都是用3层结构：Dal,Bll,Web。实践证明也是很好用的。一般就用sqlhelper做最base类，dal也就基于其上。好象在web里面的mvc模式不是很好用。因为http是要一个服务器和客户端回发的过程，不象winform。所以个人觉得winform程序用mvc比较好，但是具体怎么用，因为没有做过，所以不敢妄言，还请大家多多发言。 另：刚才看了楼上一位兄弟说的，好象winform里面可以自己写个form类，然后每个窗体都继承它。不知是否是这样。
     反正在asp.net里面是可以的，但是如果继承了自己的webform类，就无法可视化了，不好编排页面格式，这个是比较讨厌的地方。不过听说最新的vs2005就可以了。

Answer 8

争取这次能说明白一点：在创建（简单的）WinForm程序时，首先肯定是画界面。画好界面后，也就是控件都安排妥当之后，想想你希望这个程序能够展现什么？比如当某个按钮按下去后文本框就变灰等等。然后在相应的事件处理方法中实现这些功能（也就是把这些东西是现在表现曾）；然后统计界面中的控件，找到每个控件所必需响应的事件，然后添加一个类（作为内核），没发现一个必需响应的控件/界面事件，就为这个内核类添加一个方法。注意两点：1 内核类添加的只是一般的方法，而事件处理方法（也就是作为委托被添加到事件上的方法）应该实现在界面里；
2 对于功能相同的事件（比如单击工具栏按钮往往和选择某一个菜单项功能一样）则只需要添加一个方法；之后，如果界面需要根据内核的状态改变其表现，那么：1 如果界面需要在内核对象发生变化的时候立刻有所响应，请为内核类添加一个事件，并在界面中实现事件处理方法；
2 如果界面并不要立刻有所响应，请为内核添加一个状态查询方法。比如根据内核对象的不同状态，菜单项XXX需要变灰或激活，那么就为内核添加一个GetXXXStatus()的方法，然后在XXX的父菜单项弹出事件中调用这个方法，并根据返回值改变XXX的显示。最后，实现你的内核类，并在需要的时候创建更多的辅助类。至于具体的例子，我这里实在没有合适的……

Answer 9

看例子确实很有用。建议楼主找一两个开源的小项目来看看源代码（不要看那种业余的写的东西，没水平）。不过VB.net的开源项目我不清楚。