复杂的软件架构(Complex software architecture)

我已经得到了有关软件的是我工作的体系结构的几个问题！

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

社交网络（Facebook的供应，...），
公共服务（RSS，邮件，微博...）
社会bookmarkings（Digg的美味...）
聊天（MSN，AOL ...）
...

目前的架构是这样的：使用MVC和观察者/可观察的设计模式为模型（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的用户，密码）;）。

一些问题！

你认为目前的软件设计是正确的？
目前只有一个为所有的软件线程...正在为每个请求的服务会更好，一个新的线程？（例如TDigg从按钮接收一个消息时，它创建一个线程，这将创造一个TidHTTP，生成请求到服务器，等待响应，解析响应，将消息发送到每个观察者（回调），然后自由该线程。
这似乎很难全部视图/控制器与模型的各部分联系起来，是正常的，它需要这么多的作品？例如：发送与Twitter使用例如一个消息，这将需要：
- 连接的控制器（按钮）一个TApp_Core.TMicrobloggingServices_Core.TTwiter对象（模型）
- 等待用户点击按钮
- 将消息发送到TTwiter（模型）
- 创建一个线程来发送请求到服务器
- 解析来自服务器的响应
- 执行回调以通知请求已被执行，并给予结果
- 自由线程
如果我用的是以前的想法，会不会它创造了太多的线程，使计算机运行速度和更少的责任？除此之外，如果我实现一个线程池（但它是相当复杂的使用它）。
请问SQLite的3是不够好，在客户端存储的所有数据？（数据可以是邮件，RSS提要等等......所以它可以是一个相当大量的数据与次）。

谢谢，对不起我的英语不好！

Answer 1:

你认为目前的软件设计是正确的？

有可能是不客观“恰到好处”的设计 - 只有更好或更坏的设计。 :)它看起来像你在正确的轨道上，但我建议你保持你的GUI和后端服务分离的观点。例如：

     View --- Controller --- Service

所以View只知道如何呈现的东西（即IM消息，网页内容，或其他），并通过从用户请求Controller 。该Controller从接收通知Service ，并更新View 。该Service一无所知前端的（所以它可能是编写脚本，这是非常有用的），只是实现交谈的网络服务所需的协议。你必须为每个不同的后端系统单独设置这三个班的，和总控制器在全球范围内管理的应用。

这似乎很难全部视图/控制器与模型的各部分联系起来，是正常的，它需要这么多的作品？

也许，是的 - 你正在尝试一个不平凡的应用程序。我假设你正在使用的MVC风格的建筑。它可能需要更多的工作了前面正常分离的东西，但它肯定是值得的。更复杂的应用程序，你越会受益于分层和分离。

正在为每个请求的服务会更好，一个新的线程？

由于所有的服务都是基于网络的，你需要从阻塞你的主界面线程保持阻塞I / O调用（比如socket读取）。所以，你要么需要异步I / O与一个线程回调（不是很常见）充分利用，或为每个网络会话（最常用的方法），一个单独的线程。我不会推荐产生一个新的线程为每个单独的请求，但整个会话。您将需要小心避免了通常线程问题，如竞争条件和死锁（这个话题可以写一本书）。该线程将需要发布一条消息回GUI的通知，因为你不能从另一个线程的上下文中更新您的GUI。

（例如TDigg从按钮接收一个消息时，它创建一个线程，这将创造一个TidHTTP，生成请求到服务器，等待响应，解析响应，将消息发送到每个观察者（回调），然后自由该线程。

这听起来像是你有你的GUI与您的控制器和协议处理程序连接在一起。我建议你分开的前端和后端，而让事情脱钩。

如果我用的是以前的想法，会不会它创造了太多的线程，使计算机运行速度和更少的责任？

线程通常用来使计算机更加敏感。创建线程具有一定的开销，需要护理的大量工作正确同步。但如果你有每个网络会话一个线程，开销也不会慢下来，你只能最多有屈指可数。

请问SQLite的3是不够好，在客户端存储的所有数据？（数据可以是邮件，RSS提要等等......所以它可以是一个相当大量的数据与次）。

SQLite是用于这个目的的最佳数据库。它是利用一些最大的软件公司在世界上的客户端的存储管理。这是非常快速和有效的，而且我敢肯定，这将能够跟上你的应用程序。

你似乎正在进行一项复杂的应用程序。我建议你买了一本书上的并发编程，并阅读一些更多的线程。这是一个非常复杂的问题，并可能导致这是令人难以置信的难以追查，如果不是小心翼翼编程错误。祝好运！

Answer 2:

我会建议用ORM框架从数据库离开去抽象。这给你一个有意义的数据抽象层，以及，你不必担心你选择数据库的意义。 SQLite是一个不错的小型数据库。这可能是确定测试。但可以肯定的是不会削减它在一个真正的多用户环境（它具有文件级锁定，这当然会做出任何有意义的规模不可能并发CRUD）。它也只使用SQL的一个子集。使用和ORM，你可以很容易地在以后更改。