Search code examples
firebasedata-modelingdatamodel

Are there any drawbacks to very large classes as DataModel?


In my app I have multiple classes I use as part of my DM (data model). I have one class called Media which I use for multiple purposes: To help in formatting data as its created and to format it when it is fetched from the firebase.

I have been making changes to the DM and have now come across this dilema. Should I have a ~86 line DM for Media which serves both as a structure for storing data being viewed, and to format data which will be uploaded to DB. Or should I create two classes for each? Each has very similar inits and variables although some are not used in the other...

Are there drawbacks to having one class for each or to having one larger class with some unused in some situation propertys?


Solution

  • Considering that there are brilliant implementations available out of the box to serve as storage, I would not venture into creating one and reinventing the wheel; and if you need to offload object storage, you have the likes of Redis for a start.

    So, as long as you can identify a Media uniquely, use a MediaDAO (Data Access Object) to retrieve and persist Media objects from and into a Java Collection. If your programming language is not Java, find the equivalents in your language. Assuming these are large objects, you are better off not storing them in heap memory especially if there are thousands of these.

    Write a MediaVO (value object) class to format data during creation and also to format data after retrieval. If your programming language is Java, you can inherit or compose with a number of beautiful datastructure implementations built into the language.