问题标签 [design-patterns]

过去，我在许多项目中都使用过 db4o，并取得了很大的成功。随着时间的推移，它似乎有了很大的发展，随着每个人的舌头上像 LINQ 这样的现代趋势，它再次激发了我的兴趣，尤其是现在我知道它开始支持透明的激活和持久性，这让我很感兴趣，但是朋友当我第一次提到 db4o 时向我提出了一个非常好的问题，即使有了现代创新，我仍然不知道如何回答。

生成类似于大型跨表复杂约束报告的报告的最佳/最快/最常用方法是什么，可以在 SQL 等平台上如此有效地完成？我非常了解节省了多少时间、精力和开发时间，甚至获得了许多性能提升，尤其是在 ORM 上，但有些应用程序需要复杂的报告，我不知道如何使用对象和对象查询来表达，我也是担心性能，因为即使在专门为此目的设计的系统上优化和维护复杂的报告也可能是压倒性的。

--
编辑：

更清楚地说，对象数据源等可用于将 db4o 拉入与 SqlDataSource 等人相同的数据丰富的控件中。我在 db4o 站点上被提到了关于将它与 ReportViewer 一起使用的文档，并建议我将数据非规范化到报告数据库中，但这个问题意味着对如何完成查询类型提出概念挑战RDBMS 表现如此出色，以至于它们占据了整个行业。我喜欢 db4o，但如果不将所有相关对象从数据库中拉出、激活它们并执行计算，我想不出一种真正有效的方法来报告存在于几种不同类型（或 SQL 中的表）中的聚合数据在应用程序级代码中。我可能错了，但这似乎不可能

我希望在我们设法聚集在这里的聪明才智中，有人知道我不知道的事情，或者对未来的实施有创新的想法，可以扩展 ODBMS 领域。我知道各种 ORM 实现了复杂报告对象的方法，我想知道是否有任何具有这些技术经验的人可能有一些创造性的东西，不依赖于我的代码和 db4o 之外的任何技术（我可以使用单独的 SQL 服务器）。

是否有 ac# 库提供与Python PubSub库类似的功能？我认为这是一种观察者模式，它允许我订阅给定主题的消息，而不是使用事件。

我目前正在开发一个 Web 业务应用程序，该应用程序具有许多实体（人员、组织）和大量联系信息，即。多个邮政地址、电子邮件地址、电话号码等。

目前，数据库模式是这样的，个人表具有邮政地址列、电话号码列和组织表一样。这不是处理这个问题的好方法。

我已经阅读了关于此的 c2 Wiki，并且有一些关于联系人和地址模型（http://c2.com/cgi-bin/wiki?ContactAndAddressModels）以及物理地址是否过时（http://c2 .com/cgi-bin/wiki?ArePhysicalPostalAddressesArchaic）。这两次讨论真的让我对这个问题的范围大开眼界。

我正在考虑将联系信息字段分隔为单独的表。但是最好的方法是什么。目前，该应用程序主要处理芬兰地址，但它还需要处理国际地址。

我可以定义一个“地址”表、一个“电话号码”表、一个“电子邮件地址”表等等，这些将与人和组织相关联。但这感觉太像以前的解决方案：预定义的数据库模式不可避免地不够用。

我提议的是创建一个动态的联系信息架构/程序逻辑：

• 没有预定义的联系信息字段/字段集
• 用户可以随时定义新的联系信息类型和必填字段，例如
  • 芬兰邮政地址
  • 瑞典邮政地址
  • ... 邮寄地址
  • 电话号码
  • 电子邮件地址
  • ICQ号码

这可行吗？有没有人做过这样的事情？

可能有一个定义联系信息类型的表：

联系信息类型

• ID：标识符
• 名称：“芬兰邮政地址”
• 描述：“将此联系信息类型用于芬兰邮政地址”

然后可能有一个表来定义每种联系信息类型使用的字段：

联系信息类型字段

• ID：标识符
• Contact_information_type_id：参考上表
• 字段标题：“地址第 1 行”
• 字段描述：“将此行用于邮政地址的第一行”
• 字段类型：字符串/整数/等。
• 字段格式：用于验证字段数据的正则表达式
• 字段顺序：显示/使用此联系信息类型时，此字段应按什么顺序出现

然后我们将有一个“联系信息表”，它仅用于将联系信息字段映射在一起：

联系信息

• ID：标识符
• Contact_information_type_id：引用联系信息类型表

然后我们会有一个“人的联系信息” - 将不同的联系信息映射到人的表：

人的联系方式

• ID：标识符
• Contact_information_id：引用联系信息表
• 人员 id：引用人员

然后我们需要每个联系信息字段类型的表格，例如：

联系信息整数字段

等等字符串等...

最后，当显示给定人员的不同联系信息时，这将通过人员的联系信息- 表来查找用于从联系信息类型字段-表到联系信息- 表中形成此联系信息的字段。在确定使用了哪些字段之后，所有必要的表将被连接在一起。

我对 in SQL 的可行性表示怀疑。有什么想法吗？

在 Java 中，我可能可以编写一些逻辑来确定需要哪些表来形成联系信息实体，然后我可以使用某种动态 bean 在 Java 中表示这些数据。但这对我来说也有点模糊。对此也有任何想法吗？

在保存和加载不同的文件格式时，是否有一种很好用的模式？

例如，我有一个复杂的文档类层次结构，但我想支持几种不同的文件格式。

我考虑了策略模式，但我不相信，因为需要访问对象的每个部分才能保存和加载它。

在数字信号采集系统中，数据通常由一个线程推送到系统中的观察者中。

来自Wikipedia/Observer_pattern的示例：

例如，当来自例如 GUI 线程的用户操作要求数据停止流动时，您希望中​​断主体与观察者的连接，甚至一起处置观察者。

有人可能会争辩说：您应该停止数据源，并等待一个哨兵值来处理连接。但这会在系统中产生更多的延迟。

当然，如果数据泵线程刚刚询问了观察者的地址，它可能会发现它正在向被破坏的对象发送消息。

是否有人创建了一个“官方”设计模式来应对这种情况？他们不应该吗？

任何人都可以阅读 GoF 书籍来了解什么是设计模式以及如何使用它们，但是确定设计模式何时解决问题的过程是什么？模式知识是否推动了设计，或者有没有办法弄清楚如何使用模式来改变设计？

换句话说，模式有模式吗？

编辑：从另一个问题，我提供了一个答案，其中包含很多关于单身人士的问题/答案的链接：关于单身人士的更多信息：

所以我读过单例：好的设计还是拐杖？
争论仍在继续。

我将单例视为一种设计模式（好的和坏的）。

Singleton 的问题不在于模式，而在于用户（对不起大家）。每个人和他们的父亲都认为他们可以正确地实施一项（根据我所做的许多采访，大多数人都不能）。同样因为每个人都认为他们可以实现正确的单例，所以他们滥用模式并在不合适的情况下使用它（用单例替换全局变量！）。

因此，需要回答的主要问题是：

• 什么时候应该使用单例
• 如何正确实现单例

我对这篇文章的希望是，我们可以在一个地方（而不是必须谷歌和搜索多个站点）收集何时（以及如何）正确使用 Singleton 的权威来源。同样合适的是反使用列表和常见的错误实现，解释为什么它们无法工作以及好的实现它们的弱点。

所以开始吧：
我会举起手说这是我使用的，但可能有问题。
我喜欢“Scott Myers”在他的书“Effective C++”中对主题的处理

使用单例的好情况（不多）：

• 日志框架
• 线程回收池

好的。让我们一起得到一些批评和其他实现。
:-)

不要在这个问题上浪费你的时间。跟进：单身人士有什么不好？

请随意在Singleton上抱怨。

单例使用不当可能会导致大量油漆。你在使用单例时遇到过什么样的问题？这种模式的常见误用是什么？

在深入研究 Corey 的回答后，我发现了一些关于这个主题的精彩文章。

• 为什么单身人士有争议
• 高性能单例
• 单身人士是病态的骗子
• 所有单身人士都去哪儿了？
• 单身人士的根本原因

我有以下类型：

我希望使用某种专用的控制器/构建器来创建和更新这种类型，但我希望它对其他类型保持只读。

该对象还需要在其控制器/构建器每次更新时触发一个事件。

总结一下，根据前面的类型定义骨架：

• Person只能由特定控制器实例化
• 该控制器可以随时更新Person（name字段）的状态
• 发生时需要向世界其他地方Person发送通知
• 所有其他类型应该只能读取 Person属性

我应该如何实现这个？我在这里谈论的是控制器/构建器，但欢迎所有其他解决方案。

注意：我可以依赖internal修饰符，但理想情况下我所有的东西都应该在同一个程序集中。

在当今时代，事务性编程是现代开发的主要内容。并发性和容错性对于应用程序的寿命至关重要，因此，事务逻辑已变得易于实现。但是，随着应用程序的增长，事务代码似乎对应用程序的可伸缩性变得越来越沉重，当您桥接分布式事务和镜像数据集时，问题开始变得非常复杂。我很好奇，在数据大小或应用程序复杂性方面，事务经常开始成为问题的根源（导致超时、死锁、关键任务代码中的性能问题等），这些问题的修复、故障排除更麻烦或解决方法，而不是设计一个本身更容错的数据模型，或使用其他方式确保数据完整性。此外，哪些设计模式可以最大限度地减少这些影响或使标准事务逻辑过时或成为非问题？

--

编辑：到目前为止，我们已经得到了一些质量合理的答案，但我想我会自己发布一个答案，以提出我听说过的一些事情，试图激发一些额外的创造力；我得到的大部分回应都是对这个问题的悲观看法。

另一个重要的注意事项是，并非所有死锁都是由于程序编码不当造成的。有时，任务关键型操作依赖于不同顺序的相似资源，或者不同查询中的复杂连接相互叠加；这是一个有时似乎不可避免的问题，但我一直参与重新设计工作流程，以促进不太可能导致问题的执行顺序。