IOS应用架构[关闭]答案

【问题标题】：IOS App Architecture [closed]IOS应用架构[关闭]
【发布时间】：2017-02-10 12:52:08
【问题描述】：

开发我的第一个 IOS 应用程序。

关于平台 1. 使用 Restful(JSON) 服务。 2. 构建多个客户端应用程序，实现不同的功能，并有一些重叠。

实施 1. 使用 CocoaPods。 2. Infra POD/FRAMEWORK 包含整个 Infra 层和横切层。 3. 域 POD/FRAMEWORK 包含 CoreData 数据模型和使用 ActiveRecord 模式实现的模型类。 4. 每个功能作为一个单独的 POD/框架。（单个 Storyboard + 多个视图控制器） 5. 每个应用程序都声明所需的 PODS（Infra + Domain + Feature/s），并创建必要的导航流程以访问所有功能。处理身份验证。

问题 1.这可能吗？ 1. 我是否过度设计了这个？我应该从一个简单的单文件夹应用程序开始，而不是朝着某种结构工作（可能是上面的或完全不同的东西）？ 2. 有人在使用这种结构吗？有什么坑坑洼洼的吗？ 3. 是否有任何性能影响？有很多框架会阻碍启动时间吗？我可以采取任何措施来缓解这种情况。

附： : 我的UML很烂。忽略上述模型中的任何 UML 相关问题。我只是不知道macOS上有一个简单的绘图工具。

【问题讨论】：

您好，我担心多个问题合二为一，而宽泛的“最佳实践”问题不适合 Stack Overflow。其中一些可能与主题有关在programmers.stackexchange.com 单独询问但我不确定时，请务必先查看他们的常见问题解答
听起来您是在尝试聘请研究团队，而不是解决编程问题。
重复使用和干燥是我努力的两件事。我会从积极的意义上接受你的评论，因为我已经过度设计了这个问题。但我总是发现把东西扔出去比制造它们更容易。所以是时候扔掉一些东西了。 :)

标签： ios performance architecture cocoapods

【解决方案1】：

我将尝试回答这个问题：

您不必一开始就从极端的代码分离和不同的 Pod 开始。如果您以正确的方式构建代码，您可以在真正需要时轻松地分离各个部分。尽量坚持以下几点，你就不会在重用代码时遇到麻烦：

不要将您的业务逻辑（网络代码、数据库、数据持久性、数据处理等）与您的视图控制器混合。尝试为每项工作指定单独的经理。
不要复制代码！（如果必须，重组并制作，这样你就不需要复制了）
尝试真正面向对象工作（创建用于保存和存储数据、请求等的对象）
仅在必须且维护良好的情况下尝试使用框架。最好的方法是坚持使用苹果的框架，因为您知道支持不会在某个时候停止

【讨论】：

感谢 ben 的时间和 cmets。我尝试了上述结构，它确实有效（令我惊讶..）就像你提到的那样，对于非常简单的事情来说它可能太复杂了。也感谢您的建议。我一定会记住它们。