Question

I am aware that the answer to my question might involve choosing a specific approach, But I try to explain what I’m trying to find out with details:

Consider a simple 3-layer application (DAL, BLL, PL).
DAL uses EF 4.1 Code-First and access to data is wrapped up in a reposiory.

Right now, in BLL, I have Manager classes. (e.g. UserManager, ProductManager) which all derive from BaseManager. Almost each method in my Manager classes take their related entity as a parameter and perform the appropriate operations on it. e.g. in UserManager (Pseudo code):

public bool AddPermission(User user, PermissionItem permission)
{
    this.repository.Add(permission);
    this.save();
}  

Question is: My manager classes do not need to get instantiated. they can be defined static.
But if I define them static, I should create my shared methods and members (like repository, and a couple of other members) in each class (I do not want to define members like repository as static).

So do you suggest I should change my Manager classes that are indeed meant to be static to static classes? or is it ok using them as they are?

Answer 1

imho static classes are nothing more than containers for functions (and not real objects). The difference is that non-static classes can be derived and get their dependencies through the constructor.

Try to write proper tests for a static class.

You might not have intended for them to be instances today, but what about tomorrow? If you change them to static, you’ll have to refactor all your depending code to unmake them static.

I would rather start using an inversion of control container to manage their creation and instances.