发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA

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

    
2007-09-14 13:37
赞助商链接

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

2007-09-14 14:14

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

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

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

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

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

2007-09-15 09:35

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

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com