Core Data
是相当了不起的,我真的很喜欢使用the visual layout
Xcode提供它组织的东西,并获得我放置在哪里的数据的快速样本。有时候我开始怀疑我是否最好地利用了它,但是,过了一段时间后,这些箭头往往会变得难以辨别。关于如何组织Core Data可视化布局的建议?
我尝试
- 分组像物体放在一起,以保持该到最低限度,
- 抽象对象/父母与子女的树,
- 等
但混乱似乎不可避免。
您使用哪些方法来保持其最佳组织和可读性?
Core Data
是相当了不起的,我真的很喜欢使用the visual layout
Xcode提供它组织的东西,并获得我放置在哪里的数据的快速样本。有时候我开始怀疑我是否最好地利用了它,但是,过了一段时间后,这些箭头往往会变得难以辨别。关于如何组织Core Data可视化布局的建议?
我尝试
但混乱似乎不可避免。
您使用哪些方法来保持其最佳组织和可读性?
这在一般意义上很难回答。我认为这很重要,你对此给予了很好的考虑。我倾向于自己对事物的视觉安排有所迷恋,因为我发现它对我的理解和对我自己的模式的持续理解有着深远的影响。 Xcode的数据建模器本质上是一个模式设计和设计文档工具。
我努力尽可能地划分我自己的设计。例如,如果您考虑类似iTunes的情况,则可能需要一个控制器来管理库源列表选择(播放列表,一个简单示例),另一个管理选定播放列表的成员。在架构中,可能会有几个“库相关”实体和几个“播放列表相关”实体,并且肯定有几个“歌曲相关”实体(专辑,艺术家和歌曲/曲目)。我会以一种很好地安排关系线的方式将歌曲相关的东西紧紧地组合在一起,但这会使这些实体在空间上与播放列表和库相关项目在视觉上分开。换句话说,如果你把相关的项目放在明确定义的逻辑集群中,并用好的空格分开,按照组织控制器的相同方式组织,这些概念就会保持相当清晰。
另一个问题是Xcode自动放置关系线。不幸的是,我们几乎无法做到这一点。我知道花费的时间(实际时间是因为尴尬而变得不合时宜)担心的是平衡清晰描绘的关系和清晰描绘的相互关联的实体之间的关系。
祝你好运,快乐OCD! :-)
这里有更好的建议。 http://www.sebastianrehnby.com/blog/2013/01/15/structuring-an-ios-project/
此外,服务模块,辅助模块(您的应用程序的实用工具类) 服务 - (调用外部服务,如您的后端服务器,DBOject服务)
而且,这一次 http://www.slideshare.net/MassimoOliviero/architecting-ios-project