关于领域逻辑的组织主要讲了---贯穿领域层里的某些东西
1.事务脚本
“脚本”顾名思义就是“SQL语句”,当然如果我们操作数据库,必然要在一个事务中,这样就出会事务脚本的概念,估计市场是小的应用都是这样的组织的,记得8年前做广电项目的时候,就是这用他来组织代码的,如果大家看过BBS代码,大部分也是应用这种模式来组织的,优点就是上手快,但当代码复杂度达到一定程度,在也不会高兴了。
2.表模块
当然现在的企业应用大部分后面是关系型数据,加上GRID这种方式,衍生出了“表模块”方式。但这样与第一种方式并没有太大查询,无非我们操作的是DataTable而已。
3.领域对象
当然上面两种方式不太符合,我们“主谓宾”的思维方式,例如:
我吃饭
如果使用事务脚本,
吃饭(参数我)
{
begin tran
insert into 嘴(。。。)
for()
{
insert into 胃(。。。。)
}
commit tran
}
如果明天改喝了,这个就成了噩梦的开始。
当时有领域模型的概念+面向对象方式来思考,就变成了
Interface 吃
{
吃();
}
class 我: 吃
{
吃()
{//吃米饭
a=new 米饭();
...
a.吃(); (这个应用了O/R技术)
}
}
米饭就是领域对象,而不在是刻板的Insert插入胃里了,领域对象+加上AOP的事务,可以让我们更关心奇怪的业务逻辑。其实这样讲了这么多,还是在讲“责任要分清”。
1.事务脚本
“脚本”顾名思义就是“SQL语句”,当然如果我们操作数据库,必然要在一个事务中,这样就出会事务脚本的概念,估计市场是小的应用都是这样的组织的,记得8年前做广电项目的时候,就是这用他来组织代码的,如果大家看过BBS代码,大部分也是应用这种模式来组织的,优点就是上手快,但当代码复杂度达到一定程度,在也不会高兴了。
2.表模块
当然现在的企业应用大部分后面是关系型数据,加上GRID这种方式,衍生出了“表模块”方式。但这样与第一种方式并没有太大查询,无非我们操作的是DataTable而已。
3.领域对象
当然上面两种方式不太符合,我们“主谓宾”的思维方式,例如:
我吃饭
如果使用事务脚本,
吃饭(参数我)
{
begin tran
insert into 嘴(。。。)
for()
{
insert into 胃(。。。。)
}
commit tran
}
如果明天改喝了,这个就成了噩梦的开始。
当时有领域模型的概念+面向对象方式来思考,就变成了
Interface 吃
{
吃();
}
class 我: 吃
{
吃()
{//吃米饭
a=new 米饭();
...
a.吃(); (这个应用了O/R技术)
}
}
米饭就是领域对象,而不在是刻板的Insert插入胃里了,领域对象+加上AOP的事务,可以让我们更关心奇怪的业务逻辑。其实这样讲了这么多,还是在讲“责任要分清”。
当然在企业应用中领域对象的封装,还有可能会产生另一个噩梦---性能。所以“事务脚本”还是在某些时候会发光发热的。