复杂的软件架构 [英] Complex software architecture

问题描述

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

所以基本上，这个软件允许用户访问某些受欢迎的网站：

• 社交网络（Facebook，MySpace，...），


• 通用服务（RSS，邮件，Twitter ...），


• 社交书签（Digg，Delicious ...），


• 聊天（MSN，AOL ...），


• ...

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

  TApp_Core 
 TBookmarkingServices_Core 
 TDelicious（实现IBookmarkingServices）
 TDigg（实现IBookmarkingServices）
等（实现IBookmarkingServices）
 TChatServices_Core 
 TMSN（实现IChatServices）
 TGoogleChat（实现IChatServices）
 TAOLC帽子（实现IChatServices）
等... 
 TRSSServices_Core 
 ... 
  

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

一些问题！

• 你认为当前的软件设计是对的？


• 目前，所有软件目前只有一个线程...为每个服务请求创建一个新线程会更好吗？
  （例如，TDigg从一个按钮接收到一条消息，它创建一个线程，该线程将创建一个TidHTTP，生成对服务器的请求，等待响应，解析响应，向每个观察者发送消息）然后释放线程。


• 将所有View / Controller与模型的每个部分链接起来似乎很困难，这是正常的，它需要这么多的工作？
  Ex ：要发送一个消息，例如使用Twitter，它将需要：
  
  
  
  
  • 将控制器（按钮）附加到TApp_Core.TMicrobloggingServices_Core.TTwiter对象（模型）
  
  
  • 等待用户点击按钮
  
  
  • 向TTwiter（型号）发送消息
  
  
  • 创建线程将请求发送到服务器
  
  
  • 从服务器解析响应
  
  
  • 执行回调以通知请求已被执行，获得结果
  
  
  • 免费线程
  
  


• 如果我使用以前的想法，不会创建太多的线程，使计算机变得越来越不负责任了吗？除了，如果我实现一个线程池（但使用它是相当复杂的）。


• SQLite 3是否足够好存储客户端上的所有数据？ （数据可以是邮件，rss feed等，所以它可以是相当多的数据与时间）。

谢谢对我的坏英语感到抱歉！

解决方案

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

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

 查看---控制器---服务
  

所以 View 只知道如何渲染东西（即IM消息，网页内容或其他）将请求从用户传递到控制器。 控制器从服务收到通知，并更新查看。 服务什么也不知道前端（所以它可以是脚本，这是非常有用的），只是实现与网络服务通话所需的协议。您将为每个不同的后端系统分配一组这三个类，以及在全球范围内管理应用程序的整体控制器。

看起来很难将所有View / Controller与模型的每个部分进行链接

可能是的，你正在尝试一个不平凡的应用程序。我假设你正在使用一个MVC风格的架构。可能需要更多的工作才能妥善解耦事物，但绝对值得。您的应用程序越复杂，您将从分层和解耦中受益越多。

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

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

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

这听起来像你的GUI与你的控制器和协议处理程序耦合在一起，我建议你将前端如果我使用以前的想法，它不会创建太多的线程，并使其成为可能。电脑缓慢而不负责任？

线程通常用于使计算机更加一定的开销，并且需要大量的小心同步y。但是，如果您每个网络会话有一个线程，那么开销并不会降低，因为您最多只能少一些。

SQLite 3足够存储客户端上的所有数据？ （数据可以是邮件，rss feed等等，所以它可以是相当多的数据与时间）。

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

你似乎正在承担一个复杂的应用程序。我建议你购买一本并行编程的书，并阅读更多关于线程的信息。这是一个非常复杂的问题，如果没有非常小心地编程，可能导致难以追踪的错误。祝你好运！

I've got a few questions about the architecture of a software that I'm working on !

So basically, this software allow the user to access to some popular sites :

• Social networks (Facebook, MySpace, ...),
• Common services (RSS, Mails, Twitter...),
• Social bookmarkings (Digg, Delicious...),
• Chats (MSN, AOL...),
• ...

Currently the architecture looks like this : Use of MVC and Observer/Observable design patterns for interaction between the model (TApp_Core) and the user interface.

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 
 ...

So the software create an instance of TApp_Core and then depending on the user's choice, it creates some instances of other services (ex : App_Core.BookmarkingServices_Core.AddServices(Digg, User, Password);).

Some questions !

• Do you think that the current software design is right ?
• There is currently only one thread for all the software... Is creating a new thread for each request to a service would be better ? (for example the TDigg receive a message from a button, it creates a thread which will create a TidHTTP, generate the request to the server, wait for the response, parse the response, send a message to each observer (callback) and then free the thread.
• It seems very hard to link all View/Controller with each part of the model, is that normal that it requires so much works ? Ex : to send a message for example using with Twitter, it would require to :
  • Attach a controller (button) to a TApp_Core.TMicrobloggingServices_Core.TTwiter object (model)
  • wait the user to click on the button
  • Send a message to TTwiter (the model)
  • Create a thread to send the request to the server
  • Parse the response from the server
  • Execute callbacks to notify that the request has been executed and to give the result
  • Free the thread
• If I use the previous idea, won't it create too much threads and make the computer slow and less responsible ? Except, if I implement a thread pool (but it's quite complex to use it).
• Does SQLite 3 is good enough to store all data on the client ? (data can be mails, rss feed, etc... so it can be quite a lot of data with times).

Thanks and sorry for my bad English !

解决方案

Do you think that the current software design is right ?

There is probably not an objectively "right" design - there are only better or worse designs. :) It looks like you're on the right track, but I would suggest you keep your GUI and views decoupled from the back-end services. For example:

     View --- Controller --- Service

So the View only knows how to render things (ie. IM messages, web content, or whatever) and passes requests from the user to the Controller. The Controller receives notifications from the Service, and updates the View. The Service knows nothing of the front-end (so it could be scriptable, which is very useful) and just implements the protocol required to talk to the network service. You would have a separate set of these three classes for each distinct back-end system, and an overall controller to manage the app at a global level.

It seems very hard to link all View/Controller with each part of the model, is that normal that it requires so much works ?

Probably, yes - you are attempting a non-trivial application. I assume you're using an MVC-style architecture. It may require more work up front to properly decouple things, but it is definitely worth it. The more complex your application, the more you will benefit from layering and decoupling.

Is creating a new thread for each request to a service would be better ?

Given all the services are network-based, you need to keep the blocking I/O calls (such as socket reads) from blocking your main GUI thread. So you either need to use fully async I/O with callbacks on one thread (not very common), or have a separate thread for each network session (the most common approach). I would not recommend spawning a new thread for every separate request, but for an entire session. You will need to be careful to avoid the usual threading issues, such as race conditions and deadlocks (this topic could fill a book). The thread will need to post a message back to the GUI for notifications, as you cannot update your GUI from the context of another thread.

(for example the TDigg receive a message from a button, it creates a thread which will create a TidHTTP, generate the request to the server, wait for the response, parse the response, send a message to each observer (callback) and then free the thread.

That sounds like you have your GUI coupled together with your controller and protocol handler. I suggest you separate the front-end and back-end, and keep things decoupled.

If I use the previous idea, won't it create too much threads and make the computer slow and less responsible ?

Threads are normally used to make the computer more responsive. Creating threads has a certain overhead, and require a great deal of care to synchronise properly. But if you have one thread per network session, the overhead will not slow things down as you would only have at most a handful.

Does SQLite 3 is good enough to store all data on the client ? (data can be mails, rss feed, etc... so it can be quite a lot of data with times).

SQLite is an excellent database for this purpose. It is used by some of the largest software houses in the world for client-side storage management. It is very fast and efficient, and I'm sure it will be able to keep up with your application.

You seem to be undertaking a complex application. I suggest you buy a book on concurrent programming, and read some more about threading. It is a very complex issue, and can lead to bugs that are incredibly difficult to track down if not programmed with great care. Good luck!

这篇关于复杂的软件架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！