A few years ago I wrote an application using custom entity objects to pass information between my DAL and BLL layers. The object architecture was very basic and was almost a 1-1 relationship to my database schema. My design is getting somewhat complex so I'm going back to do some refactoring. I'm wondering if creating custom container classes for some of my objects is worth the effort or even necessary.

For instance, I have a Player class in my BLL that contains all of the properties and methods related to a Player:

  • public bool PlayGame(int playerID)
  • public bool GetYearlyStats(int playerID, string seasonCode)


but I also have lots of methods which seem like they may be suitable for a container class

  • public static List<Player> GetPlayers(string sportCode, string firstName, string lastName)
  • public static List<Player> GetPlayers(string sportCode, string seasonCode, bool includeRetired)
  • public static List<Player> GetPlayers(string sportCode, string seasonCode, string teamCode, bool includeRetired)
  • public static List<Player> GetPlayers(string sportCode, string seasonCode, string teamCode, bool includeRetired)
  • public static int InsertPlayer(int playerID, string sportCode, string positionCode, string firstName, string lastName, string middleName, string teamCode, int number, DateTime firstYear, int statMapID, bool retired)
  • public static bool UpdatePlayer(int playerID, string sportCode, string positionCode, string firstName, string middleName, string lastName, string teamCode, int number, DateTime firstYear, int statMapID, bool retired)
  • public static bool DeletePlayer(int playerID)


Is there any value in creating a container 'PlayerBin' class or something similar to contain all of the methods which just return collections of Players, or even the CRUD methods for a Player? Outside of better organization and intuitiveness, would there be any other advantages to splitting this Player class into 2 separate classes?