Question

我有一些关于我正在开发的软件架构的问题！

基本上，该软件允许用户访问一些热门网站：

社交网络（Facebook，MySpace，...），
公共服务（RSS，邮件，推特...），
社交书签（Digg，Delicious ...），
聊天（MSN，AOL ......），
...

目前架构如下所示： 使用MVC和Observer / Observable设计模式进行模型（TApp_Core）和用户界面之间的交互。

TApp_Core
 TBookmarkingServices_Core
  TDelicious (implement IBookmarkingServices) 
  TDigg (implement IBookmarkingServices) 
  etc... (implement IBookmarkingServices) 
 TChatServices_Core 
  TMSN (implement IChatServices) 
  TGoogleChat (implement IChatServices) 
  TAOLChat (implement IChatServices) 
  etc... 
 TRSSServices_Core 
 ...

因此软件会创建一个TApp_Core实例，然后根据用户的选择，它会创建一些其他服务的实例（例如：App_Core.BookmarkingServices_Core.AddServices（Digg，User，Password）;）。

有些问题！

你认为目前的软件设计是对的吗？
目前所有软件只有一个线程......为服务的每个请求创建一个新线程会更好吗？（例如TDigg从按钮接收消息，它创建一个线程，它将创建TidHTTP，生成对服务器的请求，等待响应，解析响应，向每个观察者发送消息（回调）然后免费线程。
将所有视图/控制器与模型的每个部分链接起来似乎很难，这是正常的，它需要这么多的工作吗？例如：要发送消息，例如使用Twitter，它需要：
- 将控制器（按钮）附加到TApp_Core.TMicrobloggingServices_Core.TTwiter对象（模型）
- 等待用户点击按钮
- 向TTwiter（模特）发送消息
- 创建一个线程以将请求发送到服务器
- 解析服务器的响应
- 执行回调以通知请求已执行并提供结果
- 释放线程
如果我使用上一个想法，它不会创建太多线程并使计算机变得缓慢且不那么负责任吗？但是，如果我实现了一个线程池（但使用起来非常复杂）。
SQLite 3是否足以存储客户端上的所有数据？（数据可以是邮件，RSS订阅等......因此，随着时间的推移可能会有很多数据。）

谢谢，抱歉我的英语不好！

Answer 1

你认为目前的软件设计是对的吗？

可能没有客观的“正确”设计 - 只有更好或更差的设计。 :)看起来你走在正确的轨道上，但我建议你保持你的GUI和视图与后端服务分离。例如：

     View --- Controller --- Service

因此View只知道如何呈现内容（即IM消息，Web内容等）并将请求从用户传递到Controller。 Controller会收到Service的通知，并更新View。 Service对前端一无所知（因此它可以编写脚本，这非常有用）并且只实现与网络服务通信所需的协议。对于每个不同的后端系统，您将拥有这三个类的单独集合，以及在全局级别管理应用程序的整体控制器。

将所有视图/控制器与模型的每个部分链接起来似乎很难，这是正常的，它需要这么多的工作吗？

可能，是的 - 你正在尝试一个非平凡的应用程序。我假设您使用的是MVC风格的架构。它可能需要更多的工作才能正确分离，但绝对值得。您的应用程序越复杂，您就越能从分层和分离中受益。

为每个服务请求创建一个新线程会更好吗？

鉴于所有服务都是基于网络的，您需要阻止阻塞I / O调用（例如套接字读取）阻止主GUI线程。因此，您需要在一个线程上使用完全异步I / O和回调（不常见），或者为每个网络会话使用单独的线程（最常见的方法）。我不建议为每个单独的请求生成一个新线程，但是对于整个会话。您需要小心避免通常的线程问题，例如竞争条件和死锁（本主题可能会填满一本书）。线程需要将消息发回GUI以进行通知，因为您无法从另一个线程的上下文更新GUI。

（例如TDigg从按钮接收消息，它创建一个线程，它将创建TidHTTP，生成对服务器的请求，等待响应，解析响应，向每个观察者发送消息（回调）然后释放线程。

听起来你将GUI与控制器和协议处理程序结合在一起。我建议你把前端和后端分开，并把东西分开。

如果我使用之前的想法，它不会创建太多线程并使计算机变得缓慢且负责吗？

线程通常用于使计算机更多响应。创建线程有一定的开销，需要非常小心才能正确同步。但是，如果每个网络会话都有一个线程，那么开销不会减慢速度，因为你最多只需要少数几个。

SQLite 3是否足以存储客户端上的所有数据？（数据可以是邮件，RSS提要等......因此，随着时间的推移，数据可能会非常多。）

SQLite是一个出色的数据库。它被世界上一些最大的软件公司用于客户端存储管理。它非常快速有效，我相信它能够跟上您的应用程序。

您似乎正在进行复杂的应用程序。我建议你买一本关于并发编程的书，并阅读更多关于线程的内容。这是一个非常复杂的问题，如果不仔细编程，可能会导致难以追踪的错误。祝你好运！

Answer 2

我建议使用ORM框架从数据库中抽象出来。这为您提供了一个有意义的数据抽象层，同时也意味着您不必担心您选择的数据库。 SQLite是一个很好的紧凑型数据库。测试可能没问题。但它确实不会在真正的多用户环境中削减它（它具有文件级锁定，这肯定会使任何有意义的并发CRUD无法实现）。它也只使用SQL的一个子集。使用和ORM，您可以在以后轻松更改。

Answer 3

查看您的帖子很难确定您的架构是否“良好”。这就是我努力的目标

有用吗？
尽量减少使其发挥作用。
随时清理您的设计。
使用工具可视化您的设计。

我发现使用像NDepend这样的工具可视化依赖性非常有用。

复杂的软件架构

3 个答案: