1、 层与层之间依赖于接口：
UI依赖于IBLL，IBLL依赖于IDAL，这样做在设计模式中叫做依赖倒置。也就是说依赖于抽象，而不是具体实现。如果今后的业务逻辑有变动可以不变程序的主体框架，灵活性较好。
2、 使用Castle对类进行管理：
由于层与层之间使用接口连接，但是毕竟要实现多态已实现实际的业务逻辑。使用Castle对类的管理机制，以依赖注入的方式，将接口对应的子类关联起来。这样做可以把变化放到运行时，维护性较好。
3、 Singleton模式的应用
关键的类型因为长期使用，而且其本身占用资源较高，使用Singleton模式，用长期占用空间换取因实例化而造成的时间上的浪费。性能较好。
觉得还存在的问题：
对于复杂业务逻辑处理的还是不太理想：
对于一个事物里有多个操作的问题是这样解决的，在IDAL中有一个方法的入口点，IBLL调用这个入口方法。在DAL扩展这个方法时进行对多个方法业务上的拼装。这样感觉好像把业务层的任务放到了数据层解决。
不过对于这个问题，现在找到了一些解决方法，在VS2003中可以使用TransactionAttribute属性将操作放到一个事务中。在VS2005中有一个Transaction的类（听说的），可以很好的解决这个问题。
下一片文章中打算研究一下这个问题，当然重心放在VS2005上，毕竟VS2003将是过去时，何况TransactionAttribute是COM+中的东西，使用起来觉得不方便。
