C# Winform - DAL and BLL - usage of static methods is good?

Question

The doubt I am encountering is regarding the usage of static methods during the implementation of DAL and BLL access layer in a winform application.

I know that there are many articles here regarding this topic but I didn't find any article which replies to my specific questions.

A brief introduction: I am developing a windows form application which will be used by many users (each of them with their account on a virtual machine - so basically each instance of the application will be executed by different users account). Since I don't need to keep the state of many objects I decided to use (until now I mean and for some operation) static methods and in particular in DAL and BLL to perform operation like: GetUserProfiles, GetProfileByUserName, AddNewUser, UpdateUserByUserID, etc... or to keep the state of the application with some information (like: the user which is currently running the application, lookup data from DB, etc..) which are expected to remain the same for the entire execution of the application.

My question / doubt: is it correct to implement these parts of access to the database with static method since the are needed just to retrieve information and, in my opinion, is not required a state since each time they will be executed it is like a new execution and a previous state is not necessary?

Is it correct my way of thinking and my approach in your opinion or am I doing something wrong which I don't see at the moment?

Thank you every one will reply and give me a suggestion on what is better to do.

Answer 1

Although the answer to this question fairly depends on the size of the your application/security/performance/Time ... but for most of the professional developers it's called "The Best Practice" witch matters.

Also some might say just KISS (keep it simple and stupid) but if you are going to consider the future you should keep following the least well know DAL best practices for you design.

Let's assume the next year your boss orders you to use Entity Framework in your code, what would you do then? if your code is just a grown up code it will need heavy workload to change all of the stuff to EF. or what happens if you change your database engine, Oracle/MySql/SqlServer? then you are in a deep trouble if you have lots of code there.

I suggest at least to use an Interface combined with using Factory Design Patterin for your DAL if you are not going to struggle with complex patterns.

Another thing to mention is that using static classes you are making your DAL single thread per user witch is not pretty good for Win Form application.

so If you want Flexibility and multi thread ability for your application it;s not the best practice, but if you just want the application to work there you are.

Answer 2

Static members (methods, properties, etc.) cannot benefit from object-orientation, i.e. polymorphism, inheritance, interface implementation etc.

If you are using a repository pattern, you can generalize things and keep the ability to add specific methods to specific repositories. A repository could be described as:

public interface IRepository<T>
{
    T GetById(int id);
    List<T> GetAll();
    void Create(T entity);
    void Delete(T entity);
    void Update(T entity);
}

This is just an example you can tailor to your needs.

As an example for flexibility, imagine a CSV exporter accepting a repository having a method

public void Export<T>(string file, IReporistory<T> repository)
{
    ...
    List<T> result = repository.GetAll();
    ...
}

In a UserProfileRepository implementing this interface you can still add a method GetProfileByUserName not defined in the interface.

If you want it more static, you can implement the interfaces as singletons.