.net三层架构_aspnet三层架构_.net三层架构是什么(9)

优点：①使代码的重用更加的高了，不需要像以前做项目，每次在一个页面反复的编写操作的代码，而使用三层架构的话，只需要把注意力放在业务逻辑层 的业务逻辑的处理和访问层的sql语句的编写。

②代码的整洁性，和易用性更加的高了。因为不同的操作都分别放在了不同的层，所以代码逻辑更加清晰，如果做好注释的话，别人能够更加清楚的理解 编写者的意图。

③可扩展型更加的高了，根据需要在不同的层编写代码，然后调用就可以了。

④非常利于团队开发。

当然了，三层架构的有点不仅仅有这些，不然也不会成为现在企业开发的基本框架，这只不过是我在开发中明显的发现的优点，拿出来跟大家分享一下。

缺点：①就是性能上肯定比以前直接在相应的页面编写操作代码上有点降低。但是这个完全是可以接受的，况且，对于我现在的水平就是代码质量上可定还 有待提高，有更大的优化空间。

②就是在我的项目中，我觉得最大的浪费就是可以在视图层直接访问访问层，因为要处理的业务逻辑实在是不多，所以还是有点代码冗余吧。所以， 以后还是要跟据自己项目的需要，来灵活的使用，不一定要按照规定必须这样做。

这仅仅是我的一点拙见，有什么地方错误，请大家积极指正。也欢迎大家跟我交流。

原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。

本文出自 “强子的专栏” 博客，请务必保留此出处

点评一下：

文章叙述还是很清楚的，发现有一两个错别字。 :)

下面聊聊技术：

我看了一下你的三层架构的代码，大体思路是清晰的，不过有些地方需要注意一下：

SqlHelper类中的各个方法，在方法开头应该对参数进行有效性检测，比如如果传入的sql参数为空串，会发生什么情况？

所有中间层（包括DAL或BLL）中的方法，都应该制订统一的异常处理策略——如果某方法中出现了未捕获的异常，应该如何处理？

另外，哪怕是小项目，也不要在页面中调用数据访问层中的方法去访问（特别是不要直接在Page_Load中new SqlConnection()），这会给项目后期维护带来很多问题。

还有，我看到你的业务逻辑层NewsBLL中的方法全部都是静态方法，在Web环境中，有可能会有多个线程同时调用同一方法，如果这些方法中有访问多线程共享资源的代码，如果不加锁，有可能会引发数据存取错误，另外，如果静态方法中的代码需要启动事务，多线程执行这一方法时也可能会带来问题。建议将静态方法改为实例方法（去掉static关键字），如果的确需要保留为静态方法，需要确认其中的代码是否是线程安全的。

首先谢谢出评价。

对于文中出现的错别字我感到非常的抱歉，恰恰这也反向的证明了老师在阅读文章时候的细致用心。对于老师的这种对于学术一丝不苟的精神，很值得我们这些学生们学习。

对于老师给我提出的问题，我也分几条给老师一个回答：

1）如果遇到传入的sql参数为空串怎么办？这个在我编写代码的时候真的没有注意到，也没有去考虑这个问题。老师提到的问题确实是一个非常严重的问题，而且我在这一块的代码也没有使用异常捕捉，如果出现空串传入，肯定会报错。因为所有代码都是我自己编写的，在我编写调用该函数的时候肯定知道自己不会传入空串。所以就没有在方法开头对传入的参数进行检测。但是对于开发就不一样了，别人可能根本不知道我这个类中各个方法是怎么编写的，当别人直接来调用我类中方法的时候，很可能会出现老师所提到的这个问题。谢谢老师的宝贵意见，也证明了我写的代码水平还仅仅是停留在自己使用的水平，没有考虑到如果别人使用会发生什么情况。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-28238-9.html