对使用net程序架构开发的一点点儿
类别: ASP.NET教程 
程序架构,功能的划分:
数据库(包括存储过程) +数据访问(包括Microsoft Application Blocks for .NET的2.0版) + 数据结构(等价于强类型DataSet) + 业务逻辑层+ 业务表现层
数据库:不用说了,就是数据库了;不包括商业逻辑的，存储过程的主要作用是完成对表的基本操，包括添加、删除、修改、选择等;
数据访问层:实现对数据库的基本操作方法,添加.修改.删除,判断是否存在,选择数据等,较细粒度的处理,不需要要考虑如检验数据合法性、多步逻辑操作等;更粗粒度的实现在业务规则层
数据结构:可以使用强类型的dataset,这一层就是c#对数据库结构的映射,提供给其他层次的调用的;
业务逻辑层:数据访问层不需要关心的数据合法等都要在这里处理了,而且这里处理内容应该都是对数据访问层的进一步封装,这里的一个函数可能调用了若干数据访问层的小的处理过程;所以这里可以说是粗粒度的实现;
业务表现层:按说这一层就是友好的操作界面了,但对于较复杂的系统,可以在这里单独处理数据的合法验证,而业务逻辑层就只需要处理业务上的逻辑了;而一般规模小的系统,业务逻辑和业务表现可以合二为一的实现;
以上这是\'纵向\'的分析,在实际的开发中为了更方便高效的开发,完全可以\'横向\'的分析,划分模块:
系统架构(通用)+权限处理(通用)+人员处理(通用)+具体业务实现+关于/帮助(通用)
所有的系统肯定都会有人使用,所以这里对权限和人员提取出来单独处理;
(欢迎批评指正 ninglng@163.com)
系统架构:主要实现,对系统的配置,常用设置的基本运行条件的处理以及整个系统的架构的实现.系统都会需要基本的运行条件的,这部分单独进行处理,做成通用的模块,以后的系统中可直接使用;
权限处理:对系统的权限进行管理,权限的处理在网上有比较多的成熟方案,形形色色,各有各的优点缺点,我们可以在吸取他们的优点的同时汇入我们自己的内容整理出符合我们通用原则的权限处理模块,对这部分内容进行各层次的封装,同系统架构做成通用的模块;
人员管理:这一模块原想加入到权限管理中,因为他们是息息相关的,但又想做成比较通用的模块,而系统对人员的处理需求又不太一样有些详细,有些粗略,很难协调,或许我们可以做成一个比较能满足大多数系统的需求的模块就可以合并到权限模块中,这样权限的设计将更加的简介高效;
关于/帮助:这个是系统或者整个公司的类似产品的关于和帮助,换个角度看就是一种广告的形式;
具体的业务:就是系统的不同之处了,也是我们工作的核心(假如上面模块的工作都已经完成),这一模块就是根据业务内容定制了,没什么好说的.
横向/纵向的划分是交插的,不是从一种角度进行的区分的.
这是个人的一点点儿想法,写在这里了,砖头等随便扔(但请不要打脸哦!)
数据库(包括存储过程) +数据访问(包括Microsoft Application Blocks for .NET的2.0版) + 数据结构(等价于强类型DataSet) + 业务逻辑层+ 业务表现层
数据库:不用说了,就是数据库了;不包括商业逻辑的，存储过程的主要作用是完成对表的基本操，包括添加、删除、修改、选择等;
数据访问层:实现对数据库的基本操作方法,添加.修改.删除,判断是否存在,选择数据等,较细粒度的处理,不需要要考虑如检验数据合法性、多步逻辑操作等;更粗粒度的实现在业务规则层
数据结构:可以使用强类型的dataset,这一层就是c#对数据库结构的映射,提供给其他层次的调用的;
业务逻辑层:数据访问层不需要关心的数据合法等都要在这里处理了,而且这里处理内容应该都是对数据访问层的进一步封装,这里的一个函数可能调用了若干数据访问层的小的处理过程;所以这里可以说是粗粒度的实现;
业务表现层:按说这一层就是友好的操作界面了,但对于较复杂的系统,可以在这里单独处理数据的合法验证,而业务逻辑层就只需要处理业务上的逻辑了;而一般规模小的系统,业务逻辑和业务表现可以合二为一的实现;
以上这是\'纵向\'的分析,在实际的开发中为了更方便高效的开发,完全可以\'横向\'的分析,划分模块:
系统架构(通用)+权限处理(通用)+人员处理(通用)+具体业务实现+关于/帮助(通用)
所有的系统肯定都会有人使用,所以这里对权限和人员提取出来单独处理;
(欢迎批评指正 ninglng@163.com)
系统架构:主要实现,对系统的配置,常用设置的基本运行条件的处理以及整个系统的架构的实现.系统都会需要基本的运行条件的,这部分单独进行处理,做成通用的模块,以后的系统中可直接使用;
权限处理:对系统的权限进行管理,权限的处理在网上有比较多的成熟方案,形形色色,各有各的优点缺点,我们可以在吸取他们的优点的同时汇入我们自己的内容整理出符合我们通用原则的权限处理模块,对这部分内容进行各层次的封装,同系统架构做成通用的模块;
人员管理:这一模块原想加入到权限管理中,因为他们是息息相关的,但又想做成比较通用的模块,而系统对人员的处理需求又不太一样有些详细,有些粗略,很难协调,或许我们可以做成一个比较能满足大多数系统的需求的模块就可以合并到权限模块中,这样权限的设计将更加的简介高效;
关于/帮助:这个是系统或者整个公司的类似产品的关于和帮助,换个角度看就是一种广告的形式;
具体的业务:就是系统的不同之处了,也是我们工作的核心(假如上面模块的工作都已经完成),这一模块就是根据业务内容定制了,没什么好说的.
横向/纵向的划分是交插的,不是从一种角度进行的区分的.
这是个人的一点点儿想法,写在这里了,砖头等随便扔(但请不要打脸哦!)
