三层架构
一般命名规范：
三层架构：
- 数据访问层（DAL）：一般只编写基本的增、删、查、改方法，不能出现业务逻辑。作用：解析对象---组合SQL；封装对象上传。
- 业务逻辑层（BLL）：一般只编写业务逻辑代码，根据用户的需求决定如何调用数据访问层的方法，不能出现任何SQL语句及数据访问代码，只能调用DAL中的方法，不能调用其他任何层的方法。作用：处理业务逻辑；传递数据。
- 用户界面层（UI）：一般只编写用户操作信息、数据验证、数据展示代码；只能调用BLL中的方法，不能调用DAL中的方法。作用：封装对象---向下传；解析对象---展示数据。
三层架构优缺点：
- 分层架构的优势：分离开发人员关注的内容；项目需求变化时程序模块可以无损替换；提高代码的复用性，当由C/S架构变为B/S架构时转换成本最低。
- 分层架构的缺点：代码量大，实现复杂。
经验总结：大中型团队项目建议使用三层架构，小型项目建议使用两层或不分层，只划分模块。
接口
接口与抽象类类似，接口侧重的是功能点的约束，是功能说明。团队开发中将相关功能定义为接口，由不同的人去实现，实现完之后按照一定的要求把实现的模块组装起来，就是一个完整的系统，大大提高了团队并行开发的能力。
抽象类和抽象方法侧重于继承，而接口侧重于功能定义与约束。不能多重继承但是可以实现多个接口。
接口定义规范：
- 使用关键字interface定义，接口类命名一般“I”开头。
- 接口中的属性、方法等，只做一个声明，而没有任何实现。
- 使用该接口的类必须实现接口中的所有方法，且方法的定义必须和接口中的方法定义的规范完全一致，因此我们也说接口具有强制性。
- 接口中的属性、方法默认都是public。
我们通常说一个类继承一个类，实现了一个或多个接口。一个类同时用继承与接口时，父类写在最前面。
接口应用总结
- 接口的应用场合：如果某一个功能需求变化较多，应使用接口保证系统的可扩展性；如果团队并行开发，可以使用接口来规范对象的使用。
- 接口编写规范：接口成员只能是一个声明；实现接口的类必须全部实现接口中规定的属性、方法。
- 特别说明：接口的使用不是必须的，要根据用户的需求来决定。
接口多态
使用接口实现多态：一个接口必须被两个或两个以上类实现；接口实现类必须转换成接口类型使用（即方法形参是接口类型，实际调用传递的接口实现类类型）。
接口和抽象类对比：
