软件架构(C#)

架构

学过软件工程的朋友应该都知道,合理的软件架构(Software Architecture)对后期的维护、新功能的添加是极为有利的。我对研究 Windows 的架构非常有兴趣,自己也想动手实践一下。但是很遗憾,我没有什么大软件的代码可以拿来研究,说句实话,就算是有,可能我也没时间去钻研。

我只好拿我以前写的一个小软件来改造,这个软件最早的一些版本结构显得不太清晰(我已经写了20多个版本啦)。也许你会觉得这对一个小软件来说没有必要,但这只是一个试验性的东西,将来这个架构也可以用于更大一些的软件。要知道系统结构对大型软件来说非常之重要,一个合理的结构会节省很多的工作量。

先简单介绍一下我的改造对象吧。AoouchWare(R) Date Convert 可以用于修改文件的创建时间、修改时间、访问时间,支持批量更改。可以对系统时间进行实时追踪。本软件基于Microdoft.NET技术编写,正常的使用需要首先安装 Microsoft.NET Framework 1.0 版或更高的版本。

从下面的图中可以看到在 SP2 版中外壳层和管理层是分开的,但是最初的 Release 版上面两层是和在一起的。所以从 SP1 版我就开始了对它的改造工作,要把一开始就定义为一个整体的两个层次完全的分开并不容易,所以我分了两步进行。SP1 版算是一个半改造的东西吧,上面两层并未完全的分离,只是把各个模块中的 文字信息提取到了一个文件 Notify.dll 中,这样的架构还不算完美。现在我的这个版本已经基本上把我头脑中的架构实现了,尽管对内存的优化还要放在下个版本中(.NET 程序的内存占用实在是太大了)。

下面简单谈一下我的研究成果吧。其实说是研究成果,只不过是把我头脑中的一些想法变成现实罢了。

我的思路说明:我的目标就是要把它分成3个层次,也就是外壳层(Shell Layer)、管理层(Manage Layer)和内核层(Kernel Layer)。外壳层主要包括 Notify.dll 和 UShell.dll,这两个是用户直接接触到的,他们的任何更改对软件功能都没有直接影响。管理主要由主程序来实现,主程序中没有任何可以进行实质性工作的代码,只是提供了对接口的管理功能,目的是把上下两层有效的衔接起来。这样即使要更新下层的代码或接口,都不会牵涉到用户层,也就是说,软件更新包的大小不会很大。核心层包括两部分,一个是环境监测(Environment),包括 EnvirChk.dll、VerRep.dll,这两个模块主要实现的是文件版本管理和环境变量管理,如果用户在更新时留下了不属于当前版本的文件,程序是不会运行的。还有一部分当然就是实现软件功能的执行(Execution)模块了,包括 FileEvt.dll、TimeChkR.dll,这个我就不多介绍了。

各个模块的具体作用:

Notify.dll 用来存储用户界面上的文字信息,也可以被其他模块调用以发出提示信息。这也为多语言程序的开发提供了便利。
UShell.dll 这是界面部分,主程序的界面是从这个文件中继承的。这样一来便实现了换肤功能。
DateCov.dll 这就是主程序,实现了对上下两层的衔接和管理。
EnvirChk.dll 这个模块用作检测环境变量,和版本管理。不合理的变量是不能被引用的,同样错误的版本将导致程序不能运行。
VerRep.dll 用来返回各个模块现在正确的版本号。
FileEvt.dll 用来调用打开文件(夹)对话框,以及执行对文件的更改。
TimeChkR.dll 可以返回当前的系统时间,以及实现对用户输入时间的标准检测,这样可以避免很多不必要的错误。

Date Convert + SP2 下载地址: http://free.efile.com.cn/aoouch/AoouchWare/DCSP2/DCSetup_CHS.exe

PlusPack for SP2 下载地址: http://free.efile.com.cn/aoouch/AoouchWare/DCSP2/DCPSetup_CHS.EXE

关于软件的下载:我发布的那个安装包是绿色的,如果你还不放心可以用 WinRAR 来解开。英文版的安装包我就不提供了,如果想用英文版的朋友可以下载 PlusPack 来实现。

时间: 2024-09-17 04:50:13

软件架构(C#)的相关文章

软件架构模式转载

概要介绍 最近一两年,转载文章越来越少了,之所以转载这篇文章,是因为看这篇文章,弄明白了我的一些问题.所以梳理了一下,结合了几篇文章. 架构模式可以帮助你定义程序的基本特征和行为.例如一些架构模式很自然让程序成为大规模(scalable)的程序.有些模式让程序变得灵巧敏捷(agile).知道这些架构的特征,优点和缺点,你就可以根据你特定的业务需求和目标从容的选择一种架构模式.作为一位架构师,你总会为自己架构选择做解释,尤其你选择一个特别的架构模式的时候.O'Reilly的这本书提供了充足的信息来

Web基础架构设计原则经典论文《架构风格与基于网络的软件架构设计》导读

1. 概述 Roy Fielding博士(见个人主页)是IETF发布的HTTP和URI协议的主要设计者.HTTP和URI是两个最为重要的Web基础技术架构协议,因此Fielding博士可谓是Web架构的奠基者之一. 除了学术上的卓越成就之外,Fielding博士还参与过很多开源软件的设计和开发工作.他是libwww-perl(世界上最早的HTTP开发库之一)的开发者,曾经负责Apache HTTP服务器中与HTTP.URI协议相关部分代码的开发.Fielding博士还指导过很多其他团队在HTTP

如何进行软件架构设计?

上次有幸给大家介绍了软件架构设计的"七种武器",对于这"七种武器"的修炼是一个漫长的过程,除了需要不断的学习理论.原理之外,还要不断的在软件架构设计的工作中去实践,而且这样的实践机会有限,因为毕竟公司的项目就那么多,失去一次这样的机会就只有等下一个项目了,所以我想在这里就具体怎样进行软件架构设计提供一些思路和方法给大家,希望能对大家在软件架构设计的工作中有所帮助. 软件架构设计的目的 对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论

小议软件架构设计要点

如何更好地进行软件架构设计,这是软件工程领域中一个永恒的重点话题.过去几十年来,国际软件工程界在软件架构设计方面已经获得了长足发展,大量图书.文章和文献记载了这方面的成熟经验与成果.软件架构设计往往是一件非常复杂的工作,涉及到很多细节和方方面面,可探讨的话题也非常之多.囿于篇幅限制,以下只能根据笔者个人理解,遴选出软件架构设计的个别要点,结合当前流行的敏捷软件工程思想,与大家分享一下自己在软件架构设计方面的心得和体会. 架构决定成败 软件架构是软件产品.软件系统设计当中的主体结构和主要矛盾.任何

ios-iOS通信软件架构跳转问题

问题描述 iOS通信软件架构跳转问题 想写一个WiFi通信的软件,首页跳转到通信界面以后,打开switch开关,如果这时候返回到首页,再次跳转到通信界面的时候,一切都初始化了,重新创建了一个UIView出来,我想跳转到旧的UIView,信息和switch开关都还是原来的状态,应该怎么架构?用到什么技术? 解决方案 storyboard和xib没怎么用过,感觉没自定义来的自由.给你一个思路: 你可以自定义这个跳转过程,从结构来看,你是用NavigationController来进行跳转的吧 开始第

Android开发软件架构思考以及经验总结

一.萌芽 作为一只编程经验并不怎么丰富的程序猿来讲,我一直觉得架构师是一个比较神秘的职业,架构设计就更加的高大上了.经过今年的几个项目,之前曾发文叙述我的从MVC到MVP项目重构实战经验,也曾说过我准备对目前手底下的项目进行重构.但是,前段时间,我改变了我的想法.开发模式的重构,仅仅只是换了一个套路,也许在重构的过程中对业务的逻辑进行了一次梳理,也是在基于前人的代码设计上进行了一些优化.但是,这远远还不够,这不是我理想中的开发场景.在项目开发的过程中,也发现存在许多的问题,但是都是一些零散的问题

嵌入式软件架构设计?

问题描述 嵌入式软件架构设计? 我是做智能电表嵌入式软件开发的,因项目需要,现打算设计一个软件架构以实现模块化编程,同时兼顾单相.三相电表.同时,方便多人合作开发.方便以后维护.大家不知有什么好的建议? 解决方案 参考下设计模式,用面向对象的方式设计软件架构,方便扩展维护 解决方案二: 谢谢,不知能否举例说明一下?

《架构师》反思:软件架构设计

最近在看<软件架构师教程>,今天就第五章<软件架构设计>总结一下,其中还有自己所联想到的.主要从以下几个方面来描述: 软件架构 ABSD 架构模式 DSSA 架构评估   软件架构 架构的定义,在业界,目前主要分为两类:结构派 和 策略派.结构派认为架构是指软件中各构件的组织结构以及各构件之前的相互关系.策略派认为软件的架构设计是要为软件的每个重要的决择进行权衡,并作出最终决定. 架构,作为系统中最重要的组成部分,对整个系统有着重要的作用: 对于软件开发而言,首先,架构设计能使系统

软件架构应该做些什么

<代码大全>第三章读书笔记   软件架构是在软件需求出来之后,软件构建开始之前的工作   架构师应该确定的事情有: 1 程序组织 架构应该定义程序中的主要构造块.  根据程序规模不同,各个构造块可能是单个类,也可能是由多个类组成的系统.每个构造块实现一个高层功能.并且每个需求都至少有一个构造块覆盖它. 定义各个构造块之间的通信规则和依赖规则   2 主要的类 架构应该详细定义或写出所用的主要的类.并指出该类如何与其他类交互. 架构不需要对所有类进行说明,使用82法则:对构成系统80%功能的20