问题标签 [architecture]

我正在开发一个介于电子邮件服务和社交网络之间的网络应用程序。我觉得它有潜力在未来变得非常大，所以我担心可扩展性。

我决定为每个活动用户创建一个单独的 SQLite 数据库，而不是使用一个集中式 MySQL/InnoDB 数据库，然后在那个时候对其进行分区：每个“分片”一个活动用户。

这样备份数据库就像每天一次将每个用户的小型数据库文件复制到远程位置一样简单。

扩大规模就像添加额外的硬盘来存储新文件一样简单。

当应用程序超出单个服务器时，我可以使用 GlusterFS 在文件系统级别将服务器链接在一起并保持不变地运行应用程序，或者安装一个简单的 SQLite 代理系统，允许每个服务器操作相邻服务器中的 sqlite 文件。

并发问题将是最小的，因为每个 HTTP 请求一次只会触及一个或两个数据库文件，在数千个中，而且 SQLite 无论如何只会阻塞读取。

我敢打赌，这种方法将使我的应用程序能够优雅地扩展并支持许多很酷和独特的功能。我赌错了吗？我错过了什么吗？

更新我决定采用一个不太极端的解决方案，到目前为止效果很好。我正在使用固定数量的分片 - 准确地说是 256 个 sqlite 数据库。每个用户都通过一个简单的散列函数分配并绑定到一个随机分片。

我的应用程序的大多数功能只需要每个请求访问一到两个分片，但有一个特别需要对 256 个分片中的 10 到 100 个不同的分片执行简单查询，具体取决于用户。测试表明，如果所有数据都缓存在 RAM 中，大约需要 0.02 秒或更短的时间。我想我可以忍受它！

更新 2.0我将应用程序移植到 MySQL/InnoDB 并且能够获得与常规请求大致相同的性能，但是对于需要分片遍历的请求，innodb 快 4-5 倍。出于这个原因，以及其他原因，我放弃了这个架构，但我希望有人能在某个地方找到它的用途......谢谢。

我是一个非常年轻的软件工程师/QA 团队负责人。我已经开发软件大约 2 年了，其中 1 年我还在一家软件开发公司担任 QA 团队的负责人。目前，我仍在担任 QA 工具的 QA 团队负责人/软件工程师。最近，我被邀请加入一群想要创办一家软件公司的朋友和同事。他们希望我成为该软件的架构师/技术主管（我只能说一个用 Java 编写的特殊聊天客户端）。我非常擅长在火下学习，而且我通过实践学到了很多东西。但是，我担心我缺乏经验会导致项目失败（或至少开发不佳）。所以我想知道你会建议我担任这个职位，尽我所能，边走边学吗？还是建议我拒绝？

如果您建议我担任该职位，请您提供一个或一个对初级 Java 架构师有益的资源？

你们能推荐一些支持 SQL Server、PostgreSQL 和 MySQL 的经济实惠的 SQL 建模工具吗？我正在研究每个许可证范围最高 300 美元。请每个答案一个工具！

谢谢！

在我几乎完成的一个最近的项目中，我们使用了一种架构，它与 Web/服务层的交互使用 XXXManager 类作为其顶层。

例如，有一个按计划运行的 Windows 服务，它将来自多个不同数据源的数据导入我们的系统。在该服务中，调用了几个“管理器”类，即 CPImportScheduleManager、CPImportProcessManager 等。

现在，这些 Manager 类所做的不仅仅是将方法传递到链上以在 Web/服务层中使用。例如，我的 UserManager.Register() 方法不仅通过较低级别的程序集持久化用户，而且还向用户发送 WAP 推送并确定使用的手机等。

有人向我建议，这种类型的架构是试图让 OOP 适应过程模型的常用方法。我可以在这里看到他们的观点，但我想知道的是，使用这个顶级类集，任何 Web/服务层都可以简单地调用相同的通用方法，而无需重写代码。因此，如果我想编写一个在某个时候注册用户的 Web 服务，我可以再次调用 UserManager.Register() 方法，而无需再次重写所有逻辑。

我从来都不是解释自己的最佳人选，但如果我的胡言乱语有道理，请随时就您的替代方案提出建议。

干杯，克里斯。

我正在使用 Reporting Services 和 Sharepoint，我有一个利用报告服务的应用程序，但是客户希望我们的应用程序集成到 sharepoint 中。目前我们与 ReportService.asmx webservice 紧密耦合，它公开了各种执行操作的方法。Reporting Services 有一种称为“Sharepoint 集成模式”的功能，启用后，报表服务器的工作方式会有所不同，Sharepoint 用于管理报表。Sharepoint 添加了一个名为 ReportService2006.asmx 的新 Web 服务，它几乎完全相同。

现在我们的应用程序使用对 ReportService 的 Web 引用，并使用服务公开的各种对象。ReportService2006 具有完全相同的对象，但它们显然位于不同的命名空间中，例如我有 2 个 Web 引用 - 每个服务 1 个，因此有一个对象 MyApplication.ReportService.CatalogItem 和另一个 MyApplication.ReportService2006.CatalogItem。

我尝试使用依赖注入将服务从我们的应用程序中抽象出来，并结合工厂模式来确定要实例化我的接口的哪个实现。这是我的界面。我已将其简化为仅包含此应用程序所需的调用。

所以我有 2 个实现，每个都实例化一个不同的 Web 服务，例如：

和

所以计划是我可以在运行时将这些注入到我的 ServiceWrapper 中。但是 - 如果您注意到该接口与 ReportService 相关联，并且某些方法返回来自 Web 引用的对象，例如 CatalogItem。因此，我的项目不会构建，因为我的 ReportService2006 实现是从不同的命名空间引用 CatalogItem。

有任何想法吗？我的方向完全错误吗？

我正在考虑构建一个混合了动态语言（python 或 ruby​​）和编译语言的应用程序，并且需要一些帮助来说服自己这是一个好主意。

我的想法是，我可以使用动态语言来快速编写大量代码，然后下降到像 c/c++ 这样的编译语言来实现性能关键代码。

我可以看到这种方法的很多好处：

1. 通过主要使用动态语言进行编码来提高生产力
2. 两种语言的库的可用性

但也有一些缺点：

1. 维护两种语言之间的桥梁
2. 依赖两种语言和语言/库错误而不是一种

这种方法的其他优点/缺点是什么？有人知道这方面的任何资源和/或最佳实践吗？

你什么时候会使用 bigtabe/simpledb 数据库和关系数据库？

我最初是按照这篇 codeproject 文章中概述的 s# 架构示例来设计我的系统的（不幸的是，我没有使用 NHibernate）。基本思想是，对于需要与持久层通信的每个域对象，您将在不同的库中拥有相应的数据访问对象。每个数据访问对象都实现一个接口，当域对象需要访问数据访问方法时，它总是针对接口进行编码，而不是针对 DAO 本身进行编码。

当时，我仍然认为这种设计非常灵活。然而，随着我的领域模型中对象数量的增加，我发现自己在质疑这里是否存在组织问题。例如，几乎域中的每个对象都以相应的数据访问对象和数据访问对象接口结束。不仅如此，而且每一个都位于不同的位置，如果我想做一些简单的事情，比如在一些命名空间周围移动，这将更难以维护。

有趣的是，这些 DAO（及其相应的接口）中的许多都是非常简单的生物——最常见的只有一个 GetById() 方法。我最终得到了一大堆对象，例如

他们的实现者通常也很琐碎。这让我想知道朝不同的方向前进是否会更简单，也许通过为简单的数据访问任务设置一个对象来改变我的策略，并为那些需要更多东西的人保留专用数据访问对象的创建复杂。

有没有人对这样的架构有任何经验？总的来说，我对设置非常满意，因为现在我唯一关心的是管理所有这些小文件。但是，我仍然想知道还有哪些其他构建数据访问层的方法。

I'm wondering if there are any architectural frameworks out there to create desktop or standalone applications, in Java or C# for instance. It seems that there are tons of them available for web applications but I can't find many good resources on frameworks or architectural best-practices for desktop development.

Ideally I would like to know if there is any source code available of desktop applications that would be considered to have a good architecture or are built with a certain framework.

更新：
这是我访问量最大的问题之一，但我仍然没有真正为我的项目找到令人满意的解决方案。我在另一个问题的答案中读到的一个想法是创建一个工具，该工具可以为您从列表中选择的项目“即时”构建解决方案。不过，我还没有尝试过。

如何构建一个非常大的应用程序？

• 一个大型解决方案中的多个小型项目/组件？
• 几个大项目？
• 每个项目一个解决方案？

以及在没有一种解决方案的情况下如何管理依赖项。注意：我正在寻找基于经验的建议，而不是您在 Google 上找到的答案（我可以自己做）。

我目前正在开发一个应用程序，它有超过 80 个 dll，每个都有自己的解决方案。管理依赖项几乎是一项全职工作。有一个自定义的内部“源代码控制”，添加了用于在各处复制依赖 dll 的功能。对我来说似乎是一个次优的解决方案，但有更好的方法吗？我担心，在实践中处理一个包含 80 个项目的解决方案会非常困难。

（上下文：winforms，而不是 web）

编辑：（如果您认为这是一个不同的问题，请给我留言）

在我看来，以下之间存在相互依赖关系：

• 应用程序的项目/解决方案结构
• 文件夹/文件结构
• 源代码控制的分支结构（如果使用分支）

但是，如果可能的话，我很难将它们分开来单独考虑。

我在这里问了另一个相关的问题。