【问题标题】:Are there any drawbacks to very large classes as DataModel?非常大的归类为数据模型有什么缺点吗?
【发布时间】:2019-09-15 12:48:28
【问题描述】:

在我的应用程序中,我有多个类用作 DM(数据模型)的一部分。我有一个名为 Media 的类,我将其用于多种目的:帮助格式化创建的数据,并在从 firebase 获取数据时对其进行格式化。

我一直在对 DM 进行更改,现在遇到了这个难题。我是否应该有一个 ~86 行的媒体 DM,它既可以用作存储正在查看的数据的结构,也可以格式化将上传到数据库的数据。或者我应该为每个创建两个类?每个都有非常相似的初始化和变量,尽管有些没有在另一个中使用......

每个类都有一个类或一个更大的类有一些在某些情况下未使用的属性有缺点吗?

【问题讨论】:

  • 这是一个独立于操作系统/语言的问题。
  • 您的意思是语言依赖吗?这个问题非常广泛,没有关于语言的背景,这是无法回答的
  • @rmaddy 不一定,swift 和 iOS 开发者会不会有一些独特的差异从而改变推荐?
  • @NCT127 我的意思是独立。答案适用于数十种语言,而不仅仅是它被标记的原始 Swift。
  • @Nick.McDermaid,你可以用任何你喜欢的方式解释我只是想知道哪一个比另一个更好。任何一个选项都有缺点吗?可能较慢的应用程序或类似的东西?这就是我问的原因

标签: firebase data-modeling datamodel


【解决方案1】:

考虑到开箱即用的出色实现可用作存储,我不会冒险创建一个并重新发明轮子;如果你需要卸载对象存储,你可以从 Redis 之类的开始。

因此,只要您可以唯一地识别媒体,就可以使用 MediaDAO(数据访问对象)从 Java Collection 中检索媒体对象并将其持久保存到 Java Collection 中。如果您的编程语言不是 Java,请查找您的语言中的等价物。假设这些是大对象,最好不要将它们存储在堆内存中,特别是如果有数千个这样的对象。

编写一个MediaVO(值对象)类在创建期间格式化数据,并在检索后格式化数据。如果您的编程语言是 Java,您可以继承或组合该语言中内置的许多漂亮的数据结构实现。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-02-19
    • 2020-11-16
    • 2019-10-05
    • 1970-01-01
    • 2012-10-29
    • 2010-09-08
    • 2018-06-24
    • 2013-12-18
    相关资源
    最近更新 更多