我有一个应用程序，我希望在后端和前端（GUI）之间进行严格的分离。
后端是带有cpp类的应用程序逻辑，前端是带有一些cpp类的QML文件，主要用作后端的适配器。
现在我想知道在后端从QAbstract * Model派生的类是否可以从设计的角度来看。
我的第一个想法是它们不应该属于后端，因为它们只是一些Qt Container类的包装器，以反映GUI中的数据。因此，可以注入指向实际数据的指针，它们只应在前端中用于显示目的，但不应在后端的任何位置使用它们。
Qt Container类当然应该属于后端。
现在我还需要一些转换和实用程序功能，它们可以操作并可能修改容器的数据。因此我写了一个'处理程序'类。但现在开始变得棘手，以保持所有内容同步，特别是没有获得bindingloops。
另一个解决方案是从QAbstract * Model派生一个类，它包装数据并具有这些转换和实用程序功能。然后他们可以调用dataChanged等函数。然后我也可以在后端使用这个类。但这是好的设计还是后端没有QAbstract * Model派生类？
由于我发现很难清楚地表达我的问题，我希望我的问题在某种程度上是可以理解的： - ）
答案 0 :(得分：2)
在100％纯设计中，我有独立于Qt模型/视图框架的模型类，然后在其上创建一个QAbstractItemModel。这将是Model-View-ViewModel架构，而不是经典的MVC。
我认为这是一个很好的设计，因为QAbstractItemModel会对演示文稿进行大量处理 - 例如列号或显示角色。如果将它们与模型分开，则可以在不触及模型的情况下更改演示文稿，模型可以更小，甚至可以在标准C ++中实现。
在实践中，如果您的模型添加/删除子项，并且您希望在视图中显示它，则C ++和Qt之间的映射变得非常麻烦。因此，除非您有特殊要求将Qt保留在模型之外，或者特别感兴趣，否则只需在后端使用基于QAbstractItemModel的类。
答案 1 :(得分：0)
这是一个经典的MVC问题，所以是的，模型属于后端，甚至是QAbstractProxy派生对象。它将允许轻松扩展，更快的响应等。
当然，如果我们谈论足够大的系统。对于没有未来扩展计划的小公司来说，MVC几乎没有什么意义。