核心数据复杂性
我正在重构旧应用程序，并正在考虑切换到核心数据。 我已经在这里和网上阅读了之前的帖子，了解与直接使用 sqlite 或包装器相比的优缺点。 使用 sqlite 包装器似乎仍然更直接，因为在我看来，偏离标准使用要么很困难，要么我找不到有效的方法来做到这一点。 例如，拥有未保存在数据库中的对象。想象一下，您可以在一家商店下载产品列表，如果有人想要某种产品，他应该将其保存在本地。 我读到了两种方法，一种具有单独的托管上下文，并用临时对象丢弃另一种方法，还阅读了有关复制模型的内容 但在我看来，它们更像是对直接使用 sqlite 时自然而然发生的事情的黑客攻击。在更复杂的查询中，我也感到有限（可能是因为我对核心数据缺乏经验）。 我知道我不是很具体，但我正在寻求建议，当已经有 sqlite 实现时，我是否真的可以从远距离迁移到核心数据中受益。坦率地说，临时对象问题本身就阻止了我切换，但也许这又是我的不足的知识。
I'm refactoring and old app and was thinking of switching to core data.
I have read previous threads here and on the web for the pros and cons compared to using directly sqlite or a wrapper.
It still seems more direct to go with a sqlite wrapper because it seems to me that deviating from the standard use is either difficult or i cant find a efficient way to do it.
For example having objects that dont get saved in the DB.Imagine a store where you could download a list of products and if one wanted a product he should save it locally .
I read about 2 approaches one having seperate managed contexts and discarting the one with the temporary objects and also read about duplicating the model
but they seem to me more as hacks for something that comes naturally when using sqlite directly.I also feel limited(maybe because of my inexperience with core data) at more complex queries .
I know im not being very specific but i was looking for advice whether i could really benefit from going the distance migrating to core data when there is already a sqlite implementation.Frankly the temporary objects issue alone discourages me from switching but again maybe its my lack of knowledge.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您觉得 Core Data 不适合您的应用程序，或者您只是对它不满意，或者您对其他东西更满意，那么不使用 Core Data 并没有什么问题。因此，如果直接使用 SQLite 对您来说很有意义，那就去吧。
也就是说，如果您将 Core Data 视为 SQLite 的直接替代品，那么您将会遇到麻烦。当您使用 SQLite 时，您会处理表和行；当您使用 Core Data 时，您处理的是对象和关系。 Core Data 框架将这些对象和关系映射到 SQLite 的表（或其他一些持久存储），因此，如果您在头脑中将对象转换回表，那么您就有点没有抓住要点。
There's nothing wrong with not using Core Data if you don't feel that it's appropriate for your application, or if you're just not comfortable with it, or if you're more comfortable with something else. So if using SQLite directly makes a lot of sense to you, go for it.
That said, if you're looking at Core Data as a drop-in replacement for SQLite, you're going to have trouble. When you use SQLite, you deal in tables and rows; when you use Core Data, you deal with objects and relationships. The Core Data framework maps those objects and relationships onto SQLite's tables (or some other persistent storage), so if you're translating objects back into tables in your head then you're sorta missing the point.