【IT168 专稿】在完成数据库和数据访问层的构建后，将着手博客系统业务逻辑层的开发，本篇将从这里开始。正如以前提到的，业务逻辑层的目的是为视图层提供操作，而它自己使用数据访问层实现与数据库的通讯。
业务逻辑层设计
事实上，在开发数据访问层时，我们已经实现了部分的业务逻辑层，即业务对象。这些业务对象实质上起着连接业务逻辑层和数据访问层的作用。然后，业务对象层实现的第二部分便是构建业务对象管理器。
业务对象管理器的任务就是负责管理业务对象的实例。业务对象管理器必须支持的操作在很大程度上依赖于具体应用程序系统的业务逻辑。从最小意义上分析，它们必须提供如下一些类似于在数据访问层中定义的操作：
? GetItem—把一个业务对象返回给视图层。
? GetList—把一个业务对象列表返回给视图层。
? Save—从视图层把一个业务对象保存到数据库。
? Delete—从数据库删除一个业务对象。
切记，业务对象管理器并不直接与数据库交互，而是使用我们以前在数据访问层所定义的操作。这使得业务对象管理器的实现非常容易—只需要调用数据访问层即可。
下面，让我们来观察一下与评论相关的业务对象管理器CommentManager的具体编码(定义于路径Code/Business下的文件Comment.cs中)。
{
return CommentDB.Count(StartRow, PageSize);
}
上述Count方法调用数据访问层对象(CommentDB)的方法以检索数据库中评论信息总数，并返回这个数字。
public static List<Comment> GetList()
{
return CommentDB.GetList();
}
上述GetList方法调用数据访问层以检索一个业务对象Comment的列表。注意，该方法使用一个DataObjectMethod属性进行修饰。这个属性能够把该方法标识为一个标准的数据操作方法。
【注意】上述DataObjectMethod属性并非是必需的，但是有了这个属性在视图层使用ObjectDataSource组件时更为容易。
篇幅所限，我们不打算再列举文件Comment.cs中定义的其他方法了，因为它们的实现逻辑基本一致——都是简单地调用我们以前在数据访问层中定义的数据访问方法。
至此，有的读者可能要问：既然这些业务对象管理器没有它们自己的实现逻辑，那么专门定义它们并没有多大意义吧?!不然。事实上，这些业务对象管理器正是放置你要实现的业务逻辑(例如安全，工作流，日志等)的位置。而且，这个业务逻辑层能够使我们实现视图层与数据访问层的解耦：如果我们想替换数据源的话，我们也只需修改数据访问层，而无需改动视图层。
在构建完所有的业务对象管理器后，很有必要对数据访问和业务逻辑层进行一番彻底的测试。你可以选择使用手工测试方案，也可以借助于现成的测试脚本(例如各种自动化单元测试)。
