我在一些（REST）iOS应用中看到他们使用“纯”模型对象，例如“产品”，核心数据对象，例如“ProductCore”，以及表示远程对象的对象，例如“ProductJSON”。
我自己通常也会使用这种架构，我认为它可以明确区分关注点。它还有一些实际的好处，例如在某些情况下我想创建一个模型对象但是还没有将它添加到核心数据中。或者我想将模型直接发送到服务器而不是将它们存储在核心数据中的其他人。
另一方面，它消耗更多内存，我必须维护更多类。它也没有必要用于内存缓存，因为核心数据有一个。临时对象（例如尚未验证的表单数据）也可以在没有性能问题的情况下被删除，因为托管对象仅在内存中保存。还有一些便携性的好处，因为任何了解Swift / ObjC的东西都能理解核心数据......至少可以通过扩展来实现可扩展性。也许子类化。
所以我想知道，是否有一种在应用程序中设置模型clases的总体首选方法？在哪个上下文中，具有纯模型对象的附加层是有意义的，哪里是过度杀伤？
编辑：我不认为这是一个“基于意见”的问题。最佳架构可以根据需求而有所不同，但哪种情况应该能够根据事实来确定。
答案 0 :(得分：1)
我不确定纯对象是什么意思。这就是我在做的事情：
服务模型表示发送到Web服务和从Web服务接收的数据，并且对应于其JSON有效负载。我编写适配器来将JSON映射到服务模型，反之亦然。
实体模型代表持久数据。这些是与我的数据模型相对应的Core Data类，并且继承自NSManagedObject。
视图模型表示视图中显示的数据。每个视图都有自己的视图模型。此方法将视图模型精确映射到视图。适配器类从实体模型和/或服务模型构建视图模型（如果要显示的数据不是持久的）。适配器将数据整形到视图中，并执行格式化日期以简化视图控制器的工作。
例如，表格视图单元格可能会显示来自多个实体模型的元素。视图模型将包含一个表示要在每个单元格中显示的数据的类，并且适配器将为每个单元格构建一个。在视图控制器中填充表视图单元格变得非常简单，可以在视图模型和单元格字段之间进行一对一映射。
这种方法可能看起来有些过分，但我发现它非常有效且值得付出努力。它极大地简化了视图控制器中的代码，使测试更容易。