如何分析ASP.NET三层结构及三层架构的缺点

如何分析ASP的缺点？NET的三层架构和三层架构，相信很多没有经验的人都不知所措。因此，本文总结了问题产生的原因及解决方法。希望你能通过这篇文章解决这个问题。

ASP.NET三层结构说明

完美三层结构的要求是：修改表示层不修改逻辑层，逻辑层不修改数据层。否则，很难说你的应用程序是多层的，还是层结构的划分和组织有问题。不同的应用有不同的理解，这只是一个概念问题。

了解ASP的原因。NET的三层结构——分为三层。

我们采用三层结构主要是为了让项目结构更清晰，分工更明确，有利于后期的维护升级。它可能不会提高性能，因为主程序模块只能在子程序模块没有完成时等待。这表明，将应用程序划分为多个层会给其执行速度带来一些损失。然而，从团队开发效率的角度来看，我们可以感受到截然不同的效果。

明确一点，三层结构不是的专利。NET，也不是专门用于数据库的技术。这是一个更通用的建筑设计理念。

这种架构在数据库设计中要注意表与表之间的关系，尽量满足父子关系。用户在功能上应该有一定的限制，不要表现出删除子表一定要小心，以免造成主表和子表的数据出现逻辑上的不一致，主表的外键在子表中没有对应的值。

对于表的综合查询方法是：

先查询主表，调用主表对应的DL。然后根据主表的记录分别查询各个子表。在将来自自表的查询结果添加到主表之后，形成了一个大的查询集。

对于表操作(添加、删除和更改):

此时只操作主表，调用主表对应的DL中的操作方法。

RL层是逻辑判断层，主要对页面上传的数据进行逻辑判断。RL层的顶部是用户界面

如何构建三层架构解决方案

创建新的空白解决方案。然后：

添加-新项目-其他项目-企业模板项目-C #构建块-数据访问(数据层，以下简称D层)

添加-新项目-其他项目-企业模板项目-C #构件-业务规则(业务层，以下简称C层)

添加-新建项目-其他项目-企业模板项目-C #构件-Web用户界面(界面层，以下简称U层)

右键单击解决方案-项目依赖项，并将U设置为依赖于D，C和C设置为依赖于D

向u添加参考d和C，向C添加参考d.

到目前为止，一个三层的架子已经搭好了。我上面说的很具体，很“蠢”。知道这件事的人都觉得我胡说八道。其实我强烈感觉很多人其实根本就不理解这个简单的过程。虽然不反对建两个“空项目”，一个“ASP.NET Web应用项目”也可以作为三层框架，也有相当一部分人认为这些“企业模板项目”其实是空项目，这是一种误解。是的，企业模板项目在解决方案资源管理器中什么也不是，但是您可以用记事本打开项目文件。看到区别了吗？后面有些东西你看不到，但是系统已经准备好了。也就是说，如果在C层的一个类中使用“使用System Data SqlClineit”，或者使用一个SqlConnection对象，在编译的时候不会出现错误，但是在“任务列表”中会产生一些“策略警告”，警告你不要把应该放在D层的东西放在C层(虽然程序是正确的，但是可读性和可维护性都打折扣)，而这个函数，空项是不能用的。

在新的TraceLWord3中，应用了“企业模板项目”。将原始的LWordTask.cs放入名为AccessTask的单个项目中。在该解决方案中，创建了一个名为InterService的新项目，该项目包含一个LWordService.cs程序文件，即“中间业务层”程序。为了不重复命名，TraceLWord3的网站被放在了WebUI项目中。有关更完整的代码，可以在CodePackage/TraceLWord3目录中找到——。

ASP.NET三层结构：面象对象与实际的结合

我们知道建造桥梁需要砖。我们应该在建桥之前准备砖块，但是为了解释顺序、连贯性和简单性。我们先建桥，在建桥的过程中需要对砖块进行复制，这样就不会再有“桥不需要的东西”了。请注意，在实践中，应该首先准备砖块。

u层其实是桥，C层是砖，D层是原材料(石头、沙子)。这也解释了为什么U-level指的是D-level并依赖于D-level(而不是U-to-C和C-to-D级别)，因为桥梁不仅需要砖块，还需要石头和沙子。

“三层结构”的缺点

有网友看了这篇文章之前的作品后质疑我，这提醒了我，文章至今没有提到“三层结构”的缺点。“三层结构”这个词

眼似乎一直都很热门，究其原因，或许是这种开发模式应用的比较普遍。但是“三层结构”却并不是百试百灵的“万灵药”，它也存在着缺点。下面就来说说它的缺点……

“三层结构”开发模式的一个非常明显的缺点就是其执行速度不够快。当然这个“执行速度”是相对于非分层的应用程序来说的。从文中所给出的时序图来看，也明显的暴露了这一缺点。TraceLWord1和TraceLWord2没有分层，直接调用的ADO.NET所提供的类来获取数据。但是，TraceLWord6确要经过多次调用才能获取到数据。在子程序模块程序没有返回时，主程序模块只能处于等待状态。所以在执行速度上，留言板的版本越高，排名却越靠后。“三层结构”开发模式，不适用于对执行速度要求过于苛刻的系统，例如：在线订票，在线炒股等等……它比较擅长于商业规则容易变化的系统。

“三层结构”开发模式，入门难度够高，难于理解和学习。这是对于初学程序设计的人来说的。以这种模式开发出来的软件，代码量通常要稍稍多一些。这往往会令初学者淹没在茫茫的代码之中。望之生畏，对其产生反感，也是可以理解的……

其实，无论哪一种开发模式或方法，都是有利有弊的。不会存在一种“万用法”可以解决任何问题。所以“三层结构”这个词眼也不会是个例外！是否采用这个模式进行系统开发，要作出比较、权衡之后才可以。切忌滥用!

看完上述内容，你们掌握如何分析ASP.NET三层结构及三层架构的缺点的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！