来讨论一些 面向对象 的设计问题吧。
0
悬赏园豆：100
[已解决问题]
解决于 2010-11-15 10:03
现在我的基础对象都在内存中（某类对象数小于百万且不常修改的我叫他基础对象），且只有一份，这样员工E1与员工E2的部门D1就会是同一个对象（内存地址相同）；请问：1. 这种设计是否有问题。
继续上段，比如一组业务子系统共用一个人事子系统，我将人事子系统作为服务提供，并将服务端（人事子系统）对象同步给客户端（使用人事的业务子系统），以期望客户端也可使用这种相同对象（标识符相同）相同地址的好处，还可减少查询和传输；请问：2. 这样是否合理。
对象的行为被我搅散，典型的业务代码是这样的，比如挂失卡：(1).在数据库标记卡挂失，(2).改变当前卡对象的状态字段为已挂失，(3).引发挂失卡事件。这样我就需要在其他对象中订阅此事件并继续业务逻辑，比如记录日志、删除控制器中的白名单项、等等；请问：3. 这样分段的代码如何保证此业务的事务性质。
这是个偏执的设计，而这个设计带来的实现细节更偏执，呜呼，对象真的好难，他大爷的。
最佳答案
0
1、没有什么问题，有问题的话请问你们公司的门有几扇？
2、没有问题
3、从设计上来说应该提出“需要保证事务性”，如何保证不是设计的事，如果你说实现的话，.NET有隐式事务，WS规范有分布式投票事务
另：
在1和2问题中，尽可能控制对象的写权限
收获园豆：100
3. 这个是不是就变成了 (1).服务对象中开始事务块，(2).数据库持久多个对象，(3).更新硬件白名单项，(4).更改对象状态；其中3、4不具备事务能力，但是3失败可回滚2不运行4，且认为4不会失败。当然了，所有对象都使用读写锁限制。
或者换另一种实现，还是有事件的，可是对象状态的回滚就麻烦了，难道都改成前置事件，呜呼。
我觉得可以不要想得这么麻烦
1、系统A开启事务
2、系统A修改对象状态
3、系统A询问是否有系统对该修改做出反应
4、系统B应答询问，做出相应修改
5、系统B通知修改完毕，一切正常
6、系统A继续询问是否有系统对该修改做出反应
7、系统C应答询问，做出相应修改，并且出错
8、系统C通过修改出错
9、系统A回滚事务
