在这次项目开发中，我们对以前用的三层结构有进行了进一步的改变，除了使用Castle的Windsor容器来管理BLL层和DAL层，在数据的封装和对数据的读取上比以前更加面向对象。
1、 对于BLL层和DAL层的类型，分别继承各自的IBLL和IDAL，使用Windsor容器以注入的方式对其进行实例化，这一点和上次一样，不再赘述。
2、 对于Model层有了一些改进。每一个Model类型会对应一个ModelCollection集合类型，例如：对于订单Order实体会有相对应的OrderCollection实体集合类型。这个集合类型继承自List<T>类型，如下：
public class OrderCollection:List<Order>
//List<T>是一个泛型类型
3、 对于ModelCollection类型中只有一个方法，就是将读取出的数据集合转化为指定Model的对象集合
4、 在Model定义中也和以往简单的数据表字段封装不同，应该说加入了少量的业务逻辑。比如说：
Order的实体类型中定义了OrderDetailCollection，也就是说明Order与OrderDetail是一对多的关系，OrderDetail实体中加入一个Order实体对象
5、 对于日志的实现加入了AOP的思想，使用Castle中的Facility.AspectSharp，对于要加入日志的方法加了一个Attribute标签，在容器中截获方法调用的消息。这样可以减少在系统成型后加入日志带来的修改量
项目中的心得：
1、 对于三层来说UI层、BLL层和DAL层要分别写入相应的代码，在这次项目中感觉我们往往会把业务层中的代码写到其他的层中，比如说：有一个需求是这样的，用户要减少订单中某件物品的采购数量，当用户减少部分数量时，应该对相应记录使用Update操作，当用户减少全部数量时，应该删除相应的记录。我原来对这种判断往往会放在UI层来判断，这次项目中我体会到，对于UI层应该只是调用一种方法，BLL层做判断
UI：Click()
{
BLL.Update();
}
BLL:
Update()
{
If(UpdateFlag)
{
DAL.Update();
}
Else
{
DAL.Delete();
}
}
DAL:
Update();
Delete();
还有，比如用户在界面上的多个类似改变状态的按钮，对于UI层来说应该是多个方法，调用的BLL也应该是多个方法，但是DAL层才应该调用一个方法，而不应该将要改变的状态在UI层就组装好。
UI：
ChangeStateToTrue()
{
BLL.ChangeStateToTrue();
}
ChangeStateToFalse()
{
BLL.ChangeStateToFalse();
}
BLL：
ChangeStateToTrue()
{
ChangeState (True)
}
ChangeStateToFalse()
{
ChangeState (False)
}
DAL：
ChangeState(State)
这些问题也许并不感觉什么严重，但是层次间的功能相对更清晰，也有助于我们进行横向开发
2、 在系统中往往会存在很多的状态，将这些状态提取出来，作为一个单独的项目，可以使用枚举来封装，可以提高代码的可读性，也给今后做这件事的人以方便,而且可以到达统一的效果.
3、 系统中的综合查询部分，对于结果的传递没有使用实体类进行传递，后来感觉综合查询本身就很灵活多变，用实体类去传递结果，显得有些困难。而且结果集本身就是依靠多个实体及实体间关系得出，又如何用一个实体去传递。即使对于每一个查询建立一个实体，对于今后的改动又如何很好的应对呢
项目中的一些遗憾：
开始想使用Castle中的AR建立ORM，但是出了一些问题，应该算是有些遗憾吧。所以后来自己去写实体中的关系，有些地方还是有些牵强，今后要加强学习
