问题标签 [architecture]

由于各种原因，我们正在编写一个新的业务对象/数据存储库。该层的要求之一是将业务规则的逻辑与实际的数据存储层分开。

可以有多个数据存储层来实现对同一个对象的访问——例如，实现大多数对象的主“数据库”数据存储源，以及实现用户对象的另一个“ldap”源。在这种情况下，用户可以选择来自 LDAP 源，可能具有稍微不同的功能（例如，无法保存/更新用户对象），但应用程序以相同的方式使用它。另一种数据存储类型可能是 Web 服务或外部数据库。

我们正在考虑通过两种主要方式来实现这一点，我和一位同事在基本层面上存在分歧，这是正确的。我想就哪一个最好用一些建议。我会尽量保持对每一个的描述尽可能中立，因为我在这里寻找一些客观的观点。

• 业务对象是基类，数据存储对象继承业务对象。客户端代码处理数据存储对象。

  在这种情况下，每个数据存储对象都继承了通用的业务规则，而客户端代码直接使用的是数据存储对象。

  这意味着客户端代码确定对给定对象使用哪种数据存储方法，因为它必须显式声明该类型对象的实例。客户端代码需要明确知道它使用的每种数据存储类型的连接信息。

  如果数据存储层为给定对象实现不同的功能，客户端代码在编译时明确知道它，因为对象看起来不同。如果数据存储方式发生变化，客户端代码也必须更新。

• 业务对象封装了数据存储对象。

  在这种情况下，业务对象直接由客户端应用程序使用。客户端应用程序将基本连接信息传递给业务层。由业务对象代码决定给定对象使用哪种数据存储方法。连接信息将是从配置文件中获取的一大块数据（客户端应用程序并不真正了解/关心它的细节），它可能是数据库的单个连接字符串，也可能是各种数据存储类型的多个连接字符串。其他数据存储连接类型也可以从另一个位置读取 - 例如，数据库中的配置表指定各种 Web 服务的 URL。

  这样做的好处是，如果将新的数据存储方法添加到现有对象，则可以在运行时设置配置设置以确定使用哪种方法，并且对客户端应用程序完全透明。如果给定对象的数据存储方法发生更改，则无需修改客户端应用程序。

• 业务对象是基类，数据源对象继承自业务对象。客户端代码主要处理基类。

  这与第一种方法类似，但客户端代码声明了基本业务对象类型的变量，并且业务对象上的 Load()/Create()/etc 静态方法返回适当的数据源类型对象。

  此解决方案的架构与第一种方法类似，但主要区别在于为给定业务对象使用哪个数据存储对象由业务层而非客户端代码决定。

我知道已经有现有的 ORM 库提供了一些这样的功能，但现在请打折扣（数据存储层有可能是用这些 ORM 库之一实现的） - 另请注意，我故意不告诉你这里使用的是什么语言，除了它是强类型的。

我在这里寻找一些关于哪种方法更好使用（或随意提出其他建议）以及原因的一般建议。

我们目前正在我的团队中进行讨论，我会对其他观点感兴趣。假设我们有一个 RESTful Web 服务，其作用是通过应用各种分析算法和服务来注释文档。清晰的基本交互：我们有一个资源，即文档集合；客户端向集合发布一个新文档，获取新文档的 URI，然后可以 GETdocURI以获取文档或 GET{docURI}/metadata以查看一般元数据，{docURI}/ne对于命名实体等。问题是一些分析可能需要很长时间才能完成。假设客户端在分析完成之前获取元数据 URI，因为它希望能够在 UI 中显示部分或增量结果。将来重复 GET 可能会产生更多结果。

我们讨论过的解决方案包括：

• 保持 HTTP 连接打开直到所有分析完成（这似乎不可扩展）
• 使用 content-lengthand accept-range headers 获取增量内容（但我们事先不知道最终内容会持续多长时间）
• 为每个资源提供一个 Atom 提要，以便客户端订阅更新事件而不是简单地获取资源（如果有许多活动文档，似乎过于复杂并且可能资源匮乏）
• 只是让 GET 返回当时可用的任何内容（但它仍然留下客户端知道我们何时完成的问题）[编辑以删除对幂等性的引用以下评论]。

对于在 RESTful 架构中处理长期或异步交互的替代方法有什么意见或建议？

伊恩

“层”和“层”有什么区别？

任何人都可以提供文章/博客的链接，讨论 MMORPG 或虚拟现实服务器或其他具有丰富 3D 客户端的系统的架构。

一些上下文：

想象一下，一家拥有 200 多名开发人员的公司最终成立了一个或多或少独立的架构团队/部门。由 20 多个不同规模的“项目”/生产应用程序组成的软件组合由负责和负责项目“架构”的团队负责人/技术负责人负责。

出于整合和控制架构以及对整个系统进行某些必要的大规模返工的必要性，除了所有急需的知识交流之外，公司决定成立一个架构部门。

• 这种事业的“做”和“不做”是什么？

• 组成这样一个架构团队的人是谁？

• 他们的职责应该是什么？

• 什么超出了他们的范围？

• 对公司有用的过渡策略是什么？

• 每当有人提到“架构团队”时，如何防止那些歪歪扭扭的表情？

• 贵公司是否已经成功地进行了这样的变革？
  为什么失败了？
  为什么会成功？

那不应该是关于“什么是架构？”的讨论（这是非常密切相关的；）。

真正有趣的一点是可以接受/现实的，甚至是安装这样一个团队的无摩擦方式，当然除了一些关于战斗的警告，最好不要开始。

由于最后一个问题我写得不好，而且大部分答案都很好，但根本不是我打算提出问题的方向，所以我将其删除并重新制作为这个问题。

我是我自己项目的独立开发者，通常是非常小的东西，但我有一些想法可能会变成 FOSS 项目。我相信文档（在不同程度上，取决于具体的项目和最终用户）、源代码控制和项目管理（包括错误跟踪、时间管理等）。但是，我不确定我应该遵循多少正式流程。

或许只需在源代码控制下保留自述文件、相关的设计/需求文档和代码内注释就足够了。或者也许有一个适合单个开发人员遵循的敏捷过程。或者，也许我应该为每个项目采用老式的瀑布模型。

如果我什至需要一个正式的流程，那么对于独立开发者来说，存在哪些流程或者可以采用哪些流程？

编辑：我意识到我正在做一些任务，比如文档和源代码控制。但是，我不确定问题的部分。作为一名独立开发人员，我应该采用更敏捷的方法（如果是，敏捷的哪个“分支” - XP？Scrum？RAD？）还是更传统的方法（瀑布式还是螺旋式？）？

我有一个网站（ASP.NET）和一些用于项目（用 C# 编写）的 winforms（.Net 2.0）。我将 web 服务 (IIS6) 用于在企业内部发送电子邮件之类的任务。

我认为 Web 服务很好，但我想根据您的经验，在 Web 服务中应该和不应该是什么？

我的任务是为我的客户奠定 SOA 的基础。目标是以独立于终端客户的方式开放各种流程，并使数据可离线使用，例如访问客户的代表。

我确实在 J2EE (Websphere) 和 Web 服务方面拥有丰富的经验，但我希望能得到有关如何构建这样一个 SOA 的建议。

陷阱在哪里？安全呢？服务的粒度应该有多细？等等

指向教程和书籍推荐的链接也很有用。

谢谢！

在 UML 组件图中对架构进行建模时，如何同时显示连接器的各种属性？喜欢

• 业务对象信息流（A->B、B->A、A<->B）
• 请求/响应方向
• 同步/异步行为

我知道其他图表类型，如序列图。但是，让这些信息在组件图中可见是有价值的。

除了关联（仅显示组件已连接）或“棒棒糖”（请求/响应）之外，还有什么可能？

我只是在阅读 SOA 和服务注册中心/UDDI 经常被提及。听起来不错，但在现实中如何使用？

• 注册表是否旨在将逻辑服务与其物理实现（端口、url 等）分离？
• 注册表是否旨在供寻找有趣服务的人浏览？
• 将应用程序硬连接到它使用的服务会是“错误的”吗？