}
«网站首页
水言木的头像

水言木

关注
粉丝
关注此人
把水言木加为好友
附言：

最新动态
  • 水言木 评论博客：用最简单的例子，从最简单的设计开始，重构着讲解设计原则与模式——从DIP中“倒置”的含义说接口的正确使用 2012-05-27 01:15
    博主总结的很好！
    尤其“不能因为有两个以上的类都有这个方法，所以就提取出来了”。在对接口的运用还不够灵活的时候，最容易犯这种错误，感觉方法名一样不提取个接口就很不爽。
    感觉在接口应用中最难的是度的把握，要不多不少不大不小刚刚好。
    在OO的路上，貌似都是得经历那么一段“拼了老命也要用接口"的日子，嘿嘿~
    支持
  • 水言木 评论博客：关于cyq．data的使用方法之VB.net 2012-05-25 21:16
    假的呀．别再上当了～～～不要再人帮助发文章了
  • 水言木 发表博客：CQRS实践(4): 领域事件 2012-05-24 00:31
    前几篇随笔中讨论了CQRS中的Command，本篇随笔中将讨论CQRS中的领域事件(Domain Event)。概念先回顾下CQRS中一个UI操作的执行过程：首先，用户在UI中点击一个按钮，继而UI层...
  • 水言木 发表博客：CQRS实践(4): 领域事件 2012-05-24 00:30
    前几篇随笔中讨论了CQRS中的Command，本篇随笔中将讨论CQRS中的领域事件(Domain Event)。概念先回顾下CQRS中一个UI操作的执行过程：首先，用户在UI中点击一个按钮，继而UI层...
  • 水言木 评论博客：利用SusuCMS快速创建网站（一） 2012-05-20 13:37
    顶！楼主有没有QQ群交流啊
  • 水言木 评论博客：百般武艺为哪般---再谈业务域的核心地位 2012-05-05 14:37
    引用我以前公司，有一位架构师，在iBatis的基础上，完成一个所谓框架，可以已经创建的数据表，自动生成业务对象，和CRUD的代码
    同意楼主的说法，现在我个人的一种感觉是，如果一个系统的业务逻辑足够复杂，那业务对象肯定得要手写，要是用生成的将来肯定会有问题。按DDD的观点，Domain Model就是the heart of software，所以这部分肯定要精心雕琢，用代码生成的方式可能一时看不到坏处，但将来慢慢的问题就出来了。
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-04-05 18:15
    引用Leder：非常感谢，对CQRS理解又多了一些～
    互相讨论，互相学习 :)
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-04-05 16:35
    返回值，像文中的例子，如果需求如此，那就不得以要让他返回一些东西，这时候就只能尽量让返回的东西越简单越好。Command返回执行结果对整个架构的主要影响是：Command将不能异步执行。...
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-04-05 16:32
    可以认为命令是最终客户可理解的一个操作，比如修改密码，发布产品，修改价格，等等。这些名词都是客户可以直接理解的，这些可以分别对应一个Command。
    你说的储存命令，不知是否笔误？在CQRS中是不保存命令的，如果使用Event Sourcing，那会保存事件（非命令）。

    这里我认为要分两种情况：

    1. 不使用Event Sourcing（事件溯源）：
    这即是本文中例子的情况，Event Sourcing并不是实现CQRS所必须的技术，而且Event Sourcing一般比较难，故这一系列文章的例子都是用最简单的CQRS，这样对未接触过CQRS
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-03-30 11:33
    tor<TCommand, TResult>的时候已经指定了返回类型。

    我看了Tiny Library的Command部分只返回bool,他的持久化是由事件部分去完成，好...其实还有第三种方案：让RegisterCommand去实现ICommand<string>，即添加ICommand<TResult>的接口，它同样也是空接口。但我感觉这种实现比较不优雅，没有文中的第二种方案来的简洁明了。...
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-03-30 11:30
    tor<TCommand, TResult>的时候已经指定了返回类型。

    我看了Tiny Library的Command部分只返回bool,他的持久化是由事件部分去完成，好...补充一点，嘿嘿。
    这个约束的问题在于，对于Controller的开发人员来讲，他并不知道应该把它约束成string，因为CommandExecutor可能在重构过程中改成返回一个对象，不仅包含了UserId，而且还包含了其它一些信息，这样Controller的代码还是不变，而且编译不会出错，但在运行时，Controller中就会有找不到CommandE
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-03-30 11:23
    tor<TCommand, TResult>的时候已经指定了返回类型。

    我看了Tiny Library的Command部分只返回bool,他的持久化是由事件部分去完成，好...如果用第一种方案，RegisterCommandExecutor将会实现ICommandExecutor<RegisterCommand, string>接口（因为User.Id是string类型，而我们希望这个Command的返回值是UserId，所以第二个泛型参数用string），所以，对于一和二，CommandBus会找不到相应的Comman
  • 水言木 发表博客：CQRS实践(3): Command执行结果的返回 2012-03-30 09:26
    上篇随笔讨论了CQRS中Command的一种基本实现。面对UI中的各种命令，Controller会创建相应的Command对象，然后将其交给CommandBus，由CommandBus统一派发到相应的...
  • 水言木 发表博客：CQRS实践(3): Command执行结果的返回 2012-03-30 09:23
    上篇随笔讨论了CQRS中Command的一种基本实现。面对UI中的各种命令，Controller会创建相应的Command对象，然后将其交给CommandBus，由CommandBus统一派发到相应的...
  • 水言木 评论博客：CQRS实践(3): Command执行结果的返回 2012-03-30 09:20
    .Send(registerCommand)
    也可以写成
    CommandBus.Send<RegisterCommand, int>(registerCommand)
    也可以写成
    CommandBus.Send<RegisterCommand, string>(registerCommand)
    这些全都可以编译通过，但是只有第三个是正确的。一旦这样的代码多起来，代码就会变得难以理解和维护。...
  • 水言木 发表博客：CQRS实践(3): Command执行结果的返回 2012-03-30 00:07
    上篇随笔讨论了CQRS中Command的一种基本实现。面对UI中的各种命令，Controller会创建相应的Command对象，然后将其交给CommandBus，由CommandBus统一派发到相应的...
  • 水言木 发表博客：CQRS实践(3): Command执行结果的返回 2012-03-30 00:06
    上篇随笔讨论了CQRS中Command的一种基本实现。面对UI中的各种命令，Controller会创建相应的Command对象，然后将其交给CommandBus，由CommandBus统一派发到相应的...
  • 水言木 发表博客：CQRS实践(3): Command执行结果的返回 2012-03-29 22:42
    上篇随笔讨论了CQRS中Command的一种基本实现。面对UI中的各种命令，Controller会创建相应的Command对象，然后将其交给CommandBus，由CommandBus统一派发到相应的...
  • 水言木 发表博客：CQRS实践(2): Command的实现 2012-03-28 11:44
    概述继续引用上篇文章中的图片（来源于Udi Dahan博客），UI中的写入操作都将被封装为一个命令中，发送给Domain Model来处理。我们遵循Domain Driven Design的设计思想，...
  • 水言木 发表博客：CQRS实践(2): Command的实现 2012-03-28 11:42
    概述继续引用上篇文章中的图片（来源于Udi Dahan博客），UI中的写入操作都将被封装为一个命令中，发送给Domain Model来处理。我们遵循Domain Driven Design的设计思想，...
  • 水言木 评论博客：CQRS实践(2): Command的实现 2012-03-28 11:40
    nt Sourcing等，本系列打算从最简单的CQRS入手实现一个基本例子，然后再考虑是否研究高级主题 :P

    PS: 不知dax大虾对文中“业务逻辑”那一段我的疑问有何看法？期待你的建议...
  • 水言木 评论博客：CQRS实践(2): Command的实现 2012-03-28 11:37
    引用我想我是青蛙：
    一直觉得这套架构把程序的开发搞的过于复杂。。。
    可能比较适合大型网站吧。。。个人看法
    如果是小网站或小系统，就不合适使用CQRS，可能也不适合使用DDD，小型系统用快速开发的方式做有时可能还更好。要应用CQRS，最基本的得有相对复杂的业务逻辑。
  • 水言木 评论博客：CQRS实践(2): Command的实现 2012-03-28 11:34
    引用redhat_gg：所有代码都贴上 ，或者提供下载研究可能更好
    谢谢建议，已添加代码下载，3Q :)
  • 水言木 发表博客：CQRS实践(2): Command的实现 2012-03-28 11:34
    概述继续引用上篇文章中的图片（来源于Udi Dahan博客），UI中的写入操作都将被封装为一个命令中，发送给Domain Model来处理。我们遵循Domain Driven Design的设计思想，...
  • 水言木 发表博客：CQRS实践(2): Command的实现 2012-03-28 09:00
    概述继续引用上篇文章中的图片（来源于Udi Dahan博客），UI中的写入操作都将被封装为一个命令中，发送给Domain Model来处理。我们遵循Domain Driven Design的设计思想，...
  • 水言木 评论博客：CQRS实践(1): 什么是CQRS 2012-03-23 17:30
    引用Wind：
    关于.Net的cqrs实现可以参考一下这个开源项目
    http://ncqrs.codeplex.com/
    嗯，有浏览过它的源代码，不过这个项目貌似很久没更新了~~
  • 水言木 评论博客：CQRS实践(1): 什么是CQRS 2012-03-23 16:21
    引用dax.net：
    引用水言木：
    @美元宝
    嗯，个人感觉CQRS带来的一个好处就是，它让读写分离变得简单又优雅~~
    准备了六七篇，后面慢慢讨论，和和~~
    支持！等待博主对DDD的分享
    说实话Evans的DDD还没有完整看完，对这些的理解也还没有很完整的串起来。到时还要请大家多多指点哈~~
  • 水言木 评论博客：CQRS实践(1): 什么是CQRS 2012-03-23 16:19
    @tubo
    这确实也是个问题，可能也要看具体问题来具体分析，届时再做些权衡~~
  • 水言木 评论博客：CQRS实践(1): 什么是CQRS 2012-03-23 16:04
    @tubo
    可否把对返回值的处理放到事件处理器中去调用呢？例如user.ChangePassword(...)触发PasswordChangedEvent，然后这个Event中带上User对象，然后在event handler中，可以再调用user上的方法，比如在handler得到相关值后，调用user.AcceptFeedback(handler中得到的值)
    这个AcceptFeedback可以改成合适的名字。
  • 水言木 评论博客：CQRS实践(1): 什么是CQRS 2012-03-23 12:26
    @美元宝
    嗯，个人感觉CQRS带来的一个好处就是，它让读写分离变得简单又优雅~~
    准备了六七篇，后面慢慢讨论，和和~~
更多
Top