【发布时间】：2011-04-17 08:40:43
【问题描述】：
大家好 我想知道作为软件架构师在设计业务实体时我们需要做哪些考虑？
感谢任何参考或帮助。
【问题讨论】：
标签： .net business-objects architecture
【发布时间】：2011-04-17 08:40:43
【问题描述】：
这是一个非常广泛的问题，但我认为您必须查看的一些高级主题包括：-
此外，您需要根据最适合您的要求考虑各种模式
- 他们会有什么样的责任模式。例如：专家业务对象
- 对象是否会包含延迟加载数据等模式。
我认为探索一些ORM like NHibernate 或像Rockford Lhotka's CSLA 这样的业务对象框架作为起点会很好。
这应该为您提供一个相当公平的起点，甚至可以帮助您确定这些框架是否满足您的特定需求，或者您是否需要其他东西。
【讨论】：
-
@In Sane - 给你一个问题：与具体的业务对象相比，并发性等方面不是更成为解决方案的问题吗？
-
@Adrian K - 我认为在某些情况下，并发方面可能仅限于业务对象本身。但是，它确实在很大程度上取决于业务对象的整体设计 + 职责。
-
@Adrian K - 根据我的经验，如果您遵循专家模式之类的模式 - 其中业务对象自己拥有与自身相关的所有内容，那么有责任知道它是陈旧的，然后传播它转发/采取行动（可能重新加载自身，然后填充更新的数据，只要没有冲突+保存它）也可以属于业务对象本身的一部分。正是从这个方面，我认为并发检测，更重要的是如何响应它，也可以成为业务对象设计的一部分
-
@In Sane - 谢谢，非常有帮助。那么我唯一的另一个问题是：您将如何构建业务对象可能用来执行这些操作的常见任务/功能 - 我假设您会将真正通用的东西移植到共享帮助器类？
-
@Adrian K - 是的。业务对象通常会使用其他提供特定功能的类，一个非常基本的示例是电子邮件，可以通过电子邮件管理器类处理。这将导致一堆“技术对象类”（如果我可以这么称呼的话），每个都执行支持“核心业务类”的特定技术任务