【ASP.NET开发】.NET三层架构简单解析
这篇文章本来应该很早就写出来的，但是一直苦于自己的精神能力有限，而且已经到了我们学校的考试周，所以时间上还是有点紧迫。关键的一点就是，找不到合理的思路来写，思路没有的话，就算是再好的素材，也写不来大家喜欢的文章。
之前已经写过关于.NET三层架的两篇文章了，一篇是《【ASP.NET开发】ASP.NET（MVC）三层架构知识的学习总结》和《【ASP.NET开发】ASP.NET对SQLServer的通用数据库访问类》。如果大家有兴趣的话，可以去读一读。当然了，这两篇文章的内容，大部分都不是自己的，自己也是看了别人的博文，然后自己总结一下，拿过来自己用罢了。这次的文章主要是自己亲自使用这些知识做了一个项目（我们学校资环学院的院网站），然后拿出来跟大家分享一下。也不要期望博主能够写出多么有水平的文章，我还是学生（大三），我也是在学习的过程中，写博客之不过是想记录自己学习过程中的点滴和记录自己的进步，如果能够顺便的帮助别人学习就更好了。同时也希望大家能够多给我提意见。
非常感谢博客园的博友 @ 守护晴天 ，@Adming，@ Qlin等博友给我提出的宝贵的修改意见。也希望大家在阅读本博文的时候，如果有什么问题，或者疑问及时的给我留言沟通，大家一起探讨。
----------------------------------------------------------------------------------
对于三层架构来说，主要是使用设计模式的思想，对于项目的各个模块实现"高内聚，低耦合"的思想。这里就不做详细的介绍了，如果大家有兴趣，可以阅读软件工程和设计模式相关文章。
对于三层架构来说，就是使用类，把我们在做项目的过程中，可能需要反复操作数据库，反复的使用某个方法等等，可能就是操作的参数不同。如果我们如果在每次使用的时候，都去编写相应的代码，无疑会增加程序员的负担。所以，为了增加方法的重用，就把这些能够重用的方法抽象成类，以供程序员在其它地方可以调用。
当然了，这也是面向对象的一部分。其中的三层所指的就是：①视图层（UI）②数据库访问层（DAL）③业务逻辑层（BLL）。当然了，还有所谓的第四层-实体层（model），这一层主要是在这三个层之间进行流动传递。但是为什么不叫四层架构。。。原因我也不知道，可能是因为实体层是外在的可以根据需要会随时变化的（如：项目后续模块的添加等）。而其它三个层，如果搭建完后，可以作为框架来使用的。。。
1)首先还是先来介绍一下实体层吧，就是我们通常所说的model
实体就是我们在开发项目过程中所要涉及的一些对象。把这些所要涉及的对象（如：新闻名称，新闻上传时间，供稿人，上传文件的名称等），都抽象成一个类。使用封装字段方法，我们可以在视图层通（主要是视图层）过实例化对象的方法，来给我们的对象的属性赋值。
简单的看一段代码吧，可能会能够更加的清楚，明白
据我自己的理解，三层架构可以算是一个团队项目开发的基本框架，在这个框架的基础上可以满足一些设计模式的需要。当然可以满足模块开发的需要。
总结：
对于我这次的开发项目来说，收获还是很多的，以前仅仅是知道有三层架构这个东西，也看书，照着别人的代码写过，但是却不能体会到这其中的真正意义。
优点：①使代码的重用更加的高了，不需要像以前做项目，每次在一个页面反复的编写操作数据库的代码，而使用三层架构的话，只需要把注意力放在业务逻辑层 的业务逻辑的处理和数据库访问层的sql语句的编写。
②代码的整洁性，和易用性更加的高了。因为不同的操作都分别放在了不同的层，所以代码逻辑更加清晰，如果做好注释的话，别人能够更加清楚的理解 编写者的意图。
③可扩展型更加的高了，根据需要在不同的层编写代码，然后调用就可以了。
④非常利于团队开发。
当然了，三层架构的有点不仅仅有这些，不然也不会成为现在企业开发的基本框架，这只不过是我在开发中明显的发现的优点，拿出来跟大家分享一下。
缺点：①就是性能上肯定比以前直接在相应的页面编写数据库操作代码上有点降低。但是这个完全是可以接受的，况且，对于我现在的水平就是代码质量上可定还 有待提高，有更大的优化空间。
②就是在我的项目中，我觉得最大的浪费就是可以在视图层直接访问数据库访问层，因为要处理的业务逻辑实在是不多，所以还是有点代码冗余吧。所以， 以后还是要跟据自己项目的需要，来灵活的使用，不一定要按照规定必须这样做。
这仅仅是我的一点拙见，有什么地方错误，请大家积极指正。也欢迎大家跟我交流。
原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。
