问题标签 [architecture]

我们有一些项目涉及构建一个应用程序，该应用程序可能由 50% 的自定义功能组成，但随后引入了 wiki、论坛和其他已经发明但我们没有发明的“轮子”组件想从头重写。

这些第三方应用程序通常有自己的数据库、主题和身份验证系统。根据我的经验，让事情像单点登录、通用主题或跨多个子应用程序中的实体标记/搜索一样工作是非常具有挑战性的问题。这种集成项目有哪些最佳实践？

到目前为止，我们的方法是尝试仔细挑选您的组件，选择具有明确定义的 API 的组件，最好是通过 HTTP（如 REST 或 SOAP），尽管这并不总是可能的（我们还没有找到一个像样的以这种方式工作的论坛）。人们是否可以向任何尝试这样做的人提出建议，因为我怀疑我们中的许多人现在越来越频繁？

It drives me nuts to hear business proponents using the term realtime for web-based systems. I'm becoming the crazy in the room, chanting, "There is no such thing as realtime on the web! We're in banking, not the rocket launch/ship navigation/airplane autopilot business!"

Anyone have anything better for performance specifications than realtime, or its horrible hybrid, near-realtime?

当然，我们可以使用简单的项目符号列表或思维导图。但是，必须有一种更好、更具交互性的方式。你在开始你的网站架构时使用什么？

我需要提交培训和旅行申请的时间越来越近了。我正在寻找未来 12 个月内旨在改进编码和软件开发、最佳实践、系统架构等的会议和课程。他们需要在美国或加拿大举行，因为我永远不会获得任何其他方面的批准.

这是我发现的一些，但我正在寻找其他建议。也将不胜感激对其中任何一个的反馈：
软件过程研讨会
软件开发最佳实践
更好的软件会议
IASA 连接

IASA 活动对我来说似乎是最接近的比赛，但没有给我足够的提前时间来请求和安排它。

（首先我要明确一点，我不是 .NET 开发人员，并且不依赖于任何其他环境。）

最近，我听说伦敦证券交易所下跌了一整天。我还听说该软件是用 .NET 编写的。到目前为止，他们在忙碌的日子里会遇到性能下降。人们似乎在指责 .NET。

我不想讨论这个故事，但它让我想起了 .NET 如何扩展的问题？.NET 有多大？

我们需要建立一个管理门户网站来支持我们的客户端/服务器应用程序。由于我们是一家 .Net 商店，因此显而易见的传统方式是在 ASP.Net 中进行。但是 Silverlight 2 将在我们发布日期之前的一段时间内推出测试版。我们是否应该考虑使用支持 WCF 后端的 silverlight 来构建整个网站？

门户的主要功能将是：用户、组和权限配置；用户配置文件设置配置；支持应用程序所需的文件的文件上传和下载。

我认为采用这种方法的主要原因是我们对 WPF 和 WCF 有很好的经验，但在 ASP.Net 方面的经验很少。无论哪种方式，我们都必须学习 ASP.Net 或 Silverlight，而学习 Silverlight 似乎是我们当前技能的更自然的延伸。

StackOverflowers 的体验中是否有什么大的禁忌？有哪些大的积极因素？

构建由许多不同类型的项目组成的系统模型的常见解决方案是创建一个模块化系统，其中每个模块负责特定类型。例如，将有用于袋熊的模块 WombatModule:IModule，其中 IModule 接口具有 GetCount()（查找袋熊数量）和 Update()（更新所有袋熊的状态）等方法。

更面向对象的方法是为每个项目类型设置类并为每个项目创建一个实例。这将使类 Wombat:IItem 具有 Update() 之类的方法（以更新这个袋熊）。

从代码的角度来看，差异可以忽略不计，但运行时差异很大。面向模块的解决方案当然更快：更少的对象创建，更容易优化所有袋熊通用的操作。

当类型和模块的数量增加时，问题就来了。要么你失去了大部分性能优势，因为每个模块只支持几个项目，要么模块的复杂性增加以适应一种通用类型的稍微不同的项目——比如胖袋熊和瘦袋熊。或两者。

至少有一次我看到它退化为糟糕的状态，而 WombatModule 所做的只是保留隐藏的 Wombat 对象的集合并循环运行它们的方法。

当性能问题比长期开发问题更小时，您能否确定使用模块而不是每个项目对象的任何架构原因？可能还有另一种可能性我失踪了？

我喜欢将接口和实现分开的想法。但如何分开？接口定义是否在单独的 .Net 程序集中？您是否有一个项目来定义解决方案的所有接口？否则接口的循环依赖是否存在问题？

在我看来，引入 ORM 工具应该可以让您的架构更整洁，但为了提高效率，我发现自己有时会绕过它并迭代 JDBC 结果集。这会导致不协调的工件缠结，而不是更清晰的架构。

这是因为我在无效的上下文中应用了该工具，还是比这更深？

你什么时候可以/应该全力以赴地使用 ORM 方法？

任何见解将不胜感激。

一点背景：

在我的环境中，我有大约 50 台客户端计算机和 1 台相当强大的 SQL Server。

我有一个桌面应用程序，其中所有 50 个客户端一直在访问数据。

该项目的数据模型出于各种原因（包括清晰度、效率等）经历了多次重组。

我的数据模型的历史

1. JDBC直接调用
2. DAO + POJO 没有 Pojos 之间的关系（基本上包装了 JDBC）。
3. 添加了实现延迟加载的 POJO 之间的关系，但只是隐藏了 DAO 间调用
4. 在看到它使数据访问变得多么“简单”（它使 POJO 之间的关系变得微不足道）并且因为它可以减少与许多相关实体一起工作时到数据库的往返次数后，跳上了 Hibernate 的潮流。
5. 因为它是一个桌面应用程序，让 Sessions 长期保持打开状态是一场噩梦，所以它最终导致了很多问题
6. 回到部分 DAO/Hibernate 方法，允许我在 DAO 幕后进行直接 JDBC 调用，同时使用 Hibernate。

我正在寻找现代文本编辑器的设计\架构指导。

现代文本编辑器意味着：

• 它支持语法高亮
• 它具有自动完成功能（类似于 IntelliSense）
• 它具有高级导航功能（增量搜索等）

以下属性将是一个加号：

• 以托管语言（Java、任何 .NET 语言）实现
• 模块化架构
• 插件支持

我对文本编辑器相关的设计\架构文档\文章、开源项目的链接非常感兴趣。

我对一般建议、OOP/设计模式书籍广告不感兴趣。

目前我正在分析SharpDevelop 代码编辑器源代码。类似项目的链接将不胜感激。