写在前面的话:在课堂上只是听老师讲过三层架构,知道大概是什么意思,我的理解就是将本来混合着写在一起的代码按功能性的不同分别写在不同的项目中,然后上层项目调用下层项目提供的接口,这样可以使代码的层次更清晰、更易于阅读。
数据访问层(Database access layer)、业务逻辑层(business logical layer)、表示层(User Interface)
数据访问层:封装了所有与数据库的交互操作。即对数据库的增、删、改、查操作,不做业务逻辑的判断。
过去使用ADO.NET连接数据库需要编写固定格式的代码,比如打开数据库连接,关闭数据库连接等。在面向对象的课程中,我们在每一个数据库访问层代码中编写重复的ADO.NET代码。那么大家有没有想到重用这些代码呢?这里我们使用了一个封装了ADO.NET方法的类---SqlHelper类,用来提高数据访问代码的可重用性。
针对模型层中的每一个类,数据访问层都有一个对应的数据访问类。比如针对User实体类,有一个对应UserService类,专门处理有关User表的数据。
对数据进行操作的代码写在DAL中,一般都是SQL语句,DAL只有对数据的操作,不能有逻辑判断。
1. 命名规则:DAL层,一般使用表名+Service,例如:EmpService。
BLL层,一般表名+BLL,例如:Emp表在BLL层命名为EmpBLL
但是这里注意一点:BLL不是简单对DAL层的转发,还包含业务逻辑。例如:“未经审核的数据不恩能够删除”这样的业务逻辑就放在BLL中。
2. 三层的有点
UI层和BLL打交道,不用处理SQL语句;开发更方便,更不容易出错。一般,UI层中没有复杂的代码,解耦合,容易改变UI层技术,如果从Winform改到asp.net只需要修改UI就可以了,如果由MsSql改成Oracle,只需要修改DAL即可。
Model是在三层中传递数据的,而且Model不属于三层中的任意一层。
那么各层之间使用Model(实体类的作用是什么呢?)
表示层中使用实体类
业务逻辑层使用实体类
在数据访问层中使用实体类
三层一般会比不分层慢,但是为了分工明确,这样的少量的性能下降时可以接受的,很多时候效率不是唯一追求因素。
原文:http://www.cnblogs.com/lit10050528/p/3596005.html