三层体系结构总结（五）

在这次项目开发中，我们对以前用的三层结构有进行了进一步的改变，除了使用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，但是出了一些问题，应该算是有些遗憾吧。所以后来自己去写实体中的关系，有些地方还是有些牵强，今后要加强学习