Splitting up a class into sub-classes

Question

I've got a business logic layer class containing access methods for each table in a database. As there are quite a few tables now I'd like to restructure it to group the methods by entity (for easier access when coding). So, from this:

BLL.Database MyDB = new BLL.Database();
BLL.Entity.User MyUser = Database.UserGetById(42);

to this:

BLL.Database MyDB = new BLL.Database();
BLL.Entity.User MyUser = Database.User.GetById(42);

I'd like the class to remain non-static if possible, with all the classes 'partial' too (to allow me to add additional methods to the main generated class). What are my options for achieving this? Here's the current layout:

namespace BLL
{
    public partial class Database
    {
     // private members..
     // constructor

     #region User
     public IQueryable<BLL.Entity.User> UserGetAll()
     {
      // ...
     }

     public BLL.Entity.User UserGetById(int UserId)
     {
      // ...
     }

     public void UserSave(ref BLL.Entity.User user)
     {
      // ...
     }

     public void UserDelete(int userId)
     {
      // ...
     }
     #endregion

     // More sets of methods for other entities in database here..
    }
}

Is this feasible?

namespace BLL
{
    public partial class Database
    {
     private _User;
     public User
     {
      if (_User == null)
      {
       _User = new User();
      }
      return _User;
     }

     // Other data access classes here..
    }

    public partial class User
    {
     public IQueryable<BLL.Entity.User> GetAll()
     {
      // ...
     }

     // GetById, Save & Delete methods here..
    }
}

Thanks.

Answer 1

Aside from the use of partial, your layout looks good. I don't think partial is going to do the trick for you as far as making the classes extensible, as partial classes must all reside in the same assembly.

A better solution would likely be creating extension methods.

Answer 2

Yes, that is feasible. In fact I implemented something a lot like that.

Of course, after doing so I heard about Linq to SQL and we started using that instead... so you might want to check that out as another option.