以前我在开发中小型企业网站的时候，都是倾向于使用明确简单的直译型代码来进行开发（asp或php），一来可以缩短开发周期，二来日后维护修改起来容易。不至于遇到连自己也看不懂的尴尬情况，的确，我到现在为止还是在采用着这一快捷而有效的方式进行小型项目的开发。

但如果遇到复杂一点的网络应用程序诸如MIS系统、ERP等，使用这种开发手段似乎就
显得有点力不从心。经常会碰到一些诸如数据库读写的安全性不足、数据库更换困难、代码编写量大、几乎无法扩展等种种的烦恼。在我寻找如何解决这些烦恼的过程中，我发现使用ASP.Net架构的分布式的N层结构来进行开发可以有效的解决以上问题。

可扩展性与可重用
构建分布式N层结构网络应用的精髓在于将程序中的业务逻辑（BLL）和数据库访问逻辑（DAL）分离成两个独立的组件。从而使你编写的代码更容易维护，适应性也更强。例如，如果你想将数据库从SQL Server改变到Oracle,将会是很容易的。你只要在数据访问逻辑层进行更换，其他众多已开发好的业务逻辑程序基本无须修改就能运行。同样的道理，如果你想将已开发好的系统从一个基于B/S结构的Web应用转移到一个桌面EXE版本的话，你只要再重新开发一个可供EXE版本调用的业务逻辑层（BLL）组件就可以了。当然，使用这种分布式N层结构还有着许多“可重用”的优秀特性...，比如，你可以将你的业务逻辑组件（BLL）放到你的服务器机群中（如果你有的话）来处理更多的请求。
同时，使用这种分布式结构进行开发，有利于我们在团队中明却责任与任务，从而能有效的调用更多的人来参与开发项目。

数据读写的安全性与性能优化
同时我们在数据库访问逻辑（DAL）层中也可以使用诸如存储过程...等手段来带来很多数据读写上的优势，
其优势主要表现在以下几个方面：

·安全性：一般我们在用ASP写数据库调用时都是直接将帐号与密码写在代码里头，这样很容易被泄露给
第三方，采用存储过程后，我们将数据库对用户设置成只开放对存储过程的数据读写，这样就避免了数据被
直接读写的可能。
·性能的优化：由于存储过程是预编译的，在首次运行存储过程时，查询优化器对其分析、优化，
并给出最终存在系统表中的计划。
·可扩展性：已开发好的数据库存储过程，可以被程序多次调用，同样也可以被其他语言所开发的程序
调用。
以上这些我使用.Net架构进行开发的一些心得，在这里发布出来，只是为了抛砖引玉，希望能得到同行的指导。我相信在程序设计结构方面、数据读写优化等方面还有着更为科学、有效的开发技巧。欢迎有在这方面同样感兴趣的朋友与我交流，共同提高！