6

For example, suppose I have a class like that:

public class PlayerInfo{
    public loadDataFromDB(){
        //some code about DB framework
    }

    public string name;
    public int age;
    //other methods
    .
    .
    .
}

I found many classes would use PlayerInfo, but loadDataFromDB() is called only when the application starts. I feel uncomfortable with it because there are so many classes depend on DB framework but never calls loadDataFromDB(). So my question is, should I separate the method loadDataFromDB() into a new class:

public class PlayerInfoHelper{
    public static void loadDataFromDB(PlayerInfo playerInfo){
        //some code about DB framework
    }
}

so that every client of PlayInfo that doesn't call loadDataFromDB() would not depend on the DB framework?

  • Maybe, maybe not. Sometimes a user likes to have things show up at their fingertips, i.e. intellisense, and searching for a class does not provide the same level of convenience. Strictly speaking though, you are cluttering the original class with unrelated code. – Frank Hileman Mar 12 '18 at 4:11
  • 1
    PlayerInfoHelper is meaningless name - Helper bring no meaning or insight into responsibilities such class would fulfill. Can you tell what it does just by looking at it's name? Please consider something like: PlayerInfoTable or PlayerInfoSQL if that's what it does. – przemo_li Mar 12 '18 at 7:17
7

The answer here is dependent on what the methods themselves are doing. With a name like loadDataFromDB() it seems that your are actually loading the object from the database. If that's the case, you should definitely be doing that elsewhere. Normally, database interactions involve transaction management, authentication of some sort, connection opening and closing, thread pool management, etc. Even if you are using an ORM, I'd still argue that separation of concerns would make a distinction between modeling domain and accessing your domain from a datastore. For one, you are potentially coupling your model to the store itself. What if you are using an in memory thread safe map for development, but want to use postgres for production? That's a bit unlikely, but believe me, datastores change often when an app must scale. Programming to a DAO interface would allow you to simplify the calling code and decouple you from the specific store.

If on the other hand, lets assume JDBC here for the sake of example, you need to turn a ResultSet into a POJO, then a constructor in your domain's class that is of the form public PlayerInfo(ResultSet rs), is perfectly acceptable in the domain model itself.

In either case, data access doesn't belong in the domain model itself. In your case, some sort of DataProvider class that loads all domain models on startup makes the most sense. This class would have a single entry point thats called in your app server's start up process. This entry point would then make calls to load all data models however you needed

3

Be wary of trying to define rigid rules that you stick to 100% of the time. The answer is always "it depends".

However, in this case I think that there would be benefits to removing the database dependency from your PlayerInfo class. For one thing, it will stop PlayerInfo from turning into a "god object". It also makes it much easier to provide an alternative, non-database strategy for loading and saving data, which will be invaluable if you want to write some automated unit tests for this class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.