MIS系列系统的架构设计理解。

本人初次注册、初次登录、初次发东西，是个初哥，请各位多多指教。本人也跟随MS技术很多年了，从VB5.0开始，到现在出到社会工作了三年，基本上都是用M$的技术，对于.NET，也有一点积累了，就随手写一下，水平不高，请大家多多指点。
很多人都在谈论三层架构，据我所见，以ASP.NET为主的项目，三层无非就是UI层（可以是页面，可以是另外一个已有系统）、业务逻辑（就是实现需求上所说的功能）和数据访问层（就是写一个通用的数据访问组件，在很多项目中使用）。但也有人会提出4层、5层......N层架构；其实，我也试过所谓的多层，只不过，虽然物理上，甚至有些逻辑上确实是分为多层了，但从更高角度上看，它还是个3层架构，一层都是数据访问层和UI层都没什么变了，而因为业务逻辑层，因为太复杂，而把它分作多个层来完成，这样从物理上一看，真像个多层系统。所以还只是个三层系统。
现在就来谈谈我对三层架构的看法，最近我正在设计一个设备管理系统，涉及的东西比较多也比较复杂，不但是简单的数据管理，还有很多流程定制，基于角色的权限管理等灵活的东西。我的设计思路还是分为三层；但实际上，出现了四层，我把中间的业务层分出来了，分为Manager层（主要实现功能逻辑）和Entity层（实现系统中各个类的数据组织，作为Manager的一个参数据或处理对象），而数据层和UI层就没什么好说了，就是把M$的DataAccess Block拿回来改一下，改成比较适合项目和公司的开发规范（因为以后类似的项目还会用到，所以要规范化），UI就是根据原型，来实现啦。
它们的关系是这样的，数据访问层接受T-SQL语句，对数据库进行存取改等操作，把结果反回Entity层，Entity层中每个类有自己的成员，如一个设备类，它是可以自描述的，它有设备的所有属性，同时通过调用数据访问层来获得数据，并填充到自己的成员中去；Manager层就调用Entity的成员（有时候是属性、有时候是方法）来实现一些具体的逻辑，关把结果回到UI层，有时候会把一个Entity类返回给UI层，也就是说，Entity除了自己是一些业务实体外，一些情况下也是Manager和UI的参数。这样做的好处是，使用得开发人员对系统中的每一个实体都很清晰。因为我们认识，面向对象的开发技术，就是一味地把一大堆的对象进行操作，让它们互相作用，而形成一个系统；这样的设计就对能体现这一点，更重要的是，开发人员，不再是看着数据进行开，而是根据设计就能进行开发了。
这就是M$网站上所说的数种业务实体的一种吧，其实我们完全可以不定义Entity层，只要用DataSet就可以啦，它同样可以把业务实体作为参数进行层间的传递，但是它对设计书的业务实体的表现能力就没那么强了，但有一种叫做强类型的DataSet，其实也就是一个派生于DataSet的类，但它根据表的字段，定义了一些成员，对这些成员进行操作就可以对数据进行操作了。我正研究这个方法，以前曾经参加过一个项目就是使用了强类型的dataset，但当时对.net的理解不足，在项目也只是担任很普通的程序职务，所以还没有真正吃透这种技术，现在回过头来看，这种技术确定很不错；就记得以前使用这种技术曾经因为DataSet一次过把所有数据都调入内存，而.NET的垃圾回收机制不太理想（希望有人能发表一下关于.NET垃圾自动回收技术的文章），而导致系统占用的内存资源过大，因为那时候我们做的是一个桌面型的单系统，所以只要运行两次这个程序，整个机器都死了，后来经过我们花很大精力去修改，才把问题解决了．
这个问题先讨论在这里，希望大家多点指点，一起进步．

转载于:https://www.cnblogs.com/Kentis/archive/2005/02/25/108982.html