如何将复杂的应用逻辑从存储过程移植到业务层

总共有 2 回复／ 1 页

eastbear2008

悄悄话
发表文章: 8
注册时间: 2007年08月07日 17:03

如何将复杂的应用逻辑从存储过程移植到业务层	2007年09月14日 13:37
标签列表 ddd(129)

按照DDD的设计理念,设计始于业务实体和服务,而不是传统上先设计数据库表,因为数据库仅仅是一个数据持久化的地方，我们应该抽象出数据存储，放到什么存储介质都可以，但现实有很多情况不得不违反这一原则，比如大数据的计费应用，必须把应用逻辑写到存储过程中,如果严格在业务层来处理会带来性能的问题，试问各位有没有好的办法解决这一问题．

slangmgh

悄悄话
发表文章: 51
注册时间: 2007年09月05日 11:14

回复:如何将复杂的应用逻辑从存储过程移植到业务层

2007年09月14日 14:14

>> 按照DDD的设计理念,设计始于业务实体和服务,而不是传统上先设计数据库表,因为数据库仅仅是一个数据持久化的地方，我们应该抽象出数据存储，放到什么存储介质都可以，但现实有很多情况不得不违反这一原则，

其实，更多的时候，数据存储方式是一种需求，而不是你可以选择的设计方案，目前很少会有客户同意将业务数据存放在非RDB中吧。所以大多数情况下，分离这两个层次不是为了能够提供多种存储方式，而是因为它们属于不同的抽象层次。

>> 比如大数据的计费应用，必须把应用逻辑写到存储过程中,如果严格在业务层来处理会带来性能的问题，试问各位有没有好的办法解决这一问题．

两方面无法兼顾。在大多数情况下，交易从存储过程移到外边应当不会有太大的问题，不过有一些确实影响性能的处理你还是可以放在存储过程中。

你只能用一种方法解决99%的问题，而另外的1%的问题你需要各种各样你想得到的方法来解决。

banq

悄悄话
发表文章: 9528
注册时间: 2002年08月03日 17:08

回复:如何将复杂的应用逻辑从存储过程移植到业务层

2007年09月15日 09:35

>复杂的应用逻辑从存储过程移植到业务层
那就是从起点出发，更换一套全新的分析思维，从对象建模开始，找出模型对象，而不是数据表，完全抛弃数据表概念，使用Hibernate等这样O/R架构，这样，数据表概念从一个软件的分析设计编程几个阶段一个都进入不了，就好像你从来没学过数据表一样。

这个主题有 2 回复／ 1 页