C++ 中的数据持久化- 建议更好的方法
我们正在开发一种复制工具，它定期将不同的文件夹从客户端计算机复制到服务器计算机。
当必须复制特定文件夹时，会在客户端创建一个复制对象（由我们的服务模块），该对象将文件夹中存在的文件内容通过网络发送到服务器。在服务器上创建一个相应的接收对象（由我们的服务模块）来接收文件。
简而言之：
客户端抽象 - 复制对象（在其自己的线程中运行），其职责是发送文件。 服务器端抽象 - 接收对象（在其自己的线程中运行），职责是接收内容并创建/更新文件。
现在出现了一个额外的要求，我们需要某些计数器，例如发送的总字节数、接收的总字节数、上次复制时间……对于每个复制的文件夹。只要我们的服务正在运行，这些计数器就需要保留（不需要在我们的服务/机器重新启动时保留它）。
为了整合这些变化，我们正在讨论两种方法。
请注意 - 需要跨复制周期维护计数器。
方法1：对象重用
使计数器成为复制、接收对象的一部分，并在服务处于活动状态时保持接收和复制对象处于活动状态。 现在对于线程，可以采取以下任何一种方法。
保持对象和线程处于活动状态（线程进入睡眠状态）。现在，在下一个复制周期中，对象和线程（唤醒线程）将被重新使用。
允许线程退出，保留复制、接收对象。现在在下一个复制周期；复制接收对象重新创建线程或从线程池获取线程。
方法2：封装
将计数器封装在一个单独的类中。现在，每当实例化接收/复制对象以复制文件夹时。要么
- 传递计数器对象，正确。到文件夹作为接收/复制对象构造函数的参数。
或者
- 接收/复制对象向管理器请求与文件夹相关的计数器对象。
其中approach1 &方法2更好，为什么？
We are working on a replicating tool, which replicates different folders from a client machine to a server machine on a periodic basis.
When a particular folder has to be replicated, a replicating object is created(by our service module) on the client side which sends the contents of the files present in the folder over the network to the server. On the server a corresponding receiving object is created(by our service module) which receives the files.
Nutshell:
Client Side Abstraction - Replication object (running in its own thread), whose responsibility is to send the files.
Server Side Abstraction - Receiving object (running in its own thread), responsibility is to receive the contents and create/update the files.
Now an additional requirement has come where we need certain counters, like total bytes sent, total bytes received, last replicating time, ... for each folder which is replicated. These counter needs to be persisted as long as our service is running (no requirement of persisting this across our service/machine reboots).
To incorporate these changes there are two approaches we are debating on.
Please Note - The counter needs to be maintained across replication cycles.
Approach1 : Object Reuse
Make counters part of replication, receiving objects and keep the receiving and replication objects alive as long as the service is alive.
Now for the thread, any of the following approach can be taken.
Keep the object as well as thread alive (the thread goes into a sleep). Now during the next replicating cycle the object and thread(awake the thread) is re-used.
Allow the thread to exit, persisting the replicating, receiving object. Now during the next replicating cycle; replicating, receiving object re-creates a thread or gets a thread from a thread pool.
Approach2 : Encapsulation
Encapsulate the counters in a separate class. Now whenever a receiving/replicating object is instantiated for replicating a folder. Either
- Pass the counter object, corr. to the folder as an argument to Receiving/Replicating object constructor.
OR
- Receiving/Replicating object asks a Manager for the counter object corr to the folder.
Among approach1 & approach2 is better and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会采用第二种方法。考虑一下您一次复制多个文件的情况。您当前的设计已经支持这一点，只需使用其复制对象生成另一个线程即可。
如果您选择第二条路线，您仍然可以让计数器对象保留在主线程中，从工作线程接收信号来更新计数器。然而，第一种方法不支持这种情况。
另一种情况：计数的实时视图。如果您有一个图形用户界面或任何显示当前数据速率等的东西，它不应该在工作线程中运行。无论如何，你都必须向 gui 线程发出信号。在那个地方完成计数已经很方便了。
总结一下：对我来说，您的案例中的第二种方法似乎更灵活。它也是对当前设计引入较少更改的设计（您仍然可以丢弃对象并保留每个复制都有其自己的对象范例）。
I would go for the second approach. Consider the scenario where you replicate more than one file at once. Your current design already supports this, just spawn another thread with its replication object.
If you go for the second route, you can still have the counter object remain in main thread, receiving signals from your worker threads to update the counters. The first approach, however, would not support this scenario.
Another scenario: Live view of the counts. If you have a gui or whatever that presents current data rate etc., it should not run in the worker thread. You would have to signal to the gui thread anyway. Having counting done at that place already comes handy.
To summarise: For me it seems that the second approach in your case is the more flexible one. It is also the one that introduces less changes to the current design (you can still throw away your objects and stay with the each replication has its own object paradigm).