.net应用程序分层的个人认识

我在进行.NET应用程序开发时，经常听到三层架构，多层架构，MVC架构等等。我用过和了解过的架构很少，今天看了看以前在大学时写的一个.net应用程序，感觉好多冗余代码、架构很含糊，突然间感觉对程序的分层，搭建架构有了一个新的认识。

   说分层吧，我们经常说到的那些架构，我感觉都有一些共同的特点：程序结构清晰，软件易于维护、扩展，提高开发效率。现在比较实用、流行的框架，我想大概是那些走在前面的大牛们，经过了大量的摸索、实践、总结得出来的劳动成果，这个社会的生产效率也因为他们的奉献得到了提高。

   在做应用程序做架构设计时，我个人的感觉：职责、内容明确，清晰很重要。

假如，我的程序分为数据访问层，业务逻辑层，表现层。

搭建了数据访问层，就要给出它职责、内容的明确定义；那些直接与数据库打交道的事，都交给数据访问层去做，在其他层就不应该有SqlConnection，SqlCommand；当程序出现数据库访问、操作的bug时，首先就可以不要找其他层的问题，因为前面给予了数据访问层明确的职责和内容定义，这个时候是该它履行权利和义务的时候了。说回来，本属于业务逻辑层的职责，数据访问层就不要插手，例如注册用户名时，用户名是否存在的判断，数据访问层就没有权利下结论，只需根据业务逻辑层的请求，是查询所有已经存在的用户名呢，还是查询指定的用户名。

同理，业务逻辑层、表现层类似的给出它们明确的职责，内容的定义。尤其是对于有些内容放哪里都好像可以，这个时候就看前期各层之间职责、内容的清晰、明确度定义的如何了。本来同一个业务功能是放哪里都可以，想想应用程序不分层设计时不就是这样吗。既然分三层或多层了，那么当类似用户名、密码不能为空的判断，到底是放在表现层呢，还是业务逻辑层；就应该不用犹豫；犹豫的话，说明前面定义职责或内容不够明确和清晰，说不定时间一长，就出现了很多冗余的代码。

我猜想那些经验丰富的大牛们，应该是不局限于用什么架构的吧，我猜想他们的脑海中有自己定义的架构，他们正在工作中实践总结。

没事写下所感所想，个人经验不足，理解过于肤浅，忘莫笑话。