Static methods vs instance methods in BLL

Question

Was asked today why I used code like this for my bll classes in an asp.net app:

public class StudentBll
{
    public static DataTable GetStudents()
    {
        return DBHelper.ExecuteSp("GetStudents");
    }
    public static DataTable GetStudentById(int studentId) 
    {
        return DBHelper.ExecuteSp("GetStudentById", studentId);
    }
}

instead of

public class StudentBll
{
    public DataTable GetStudents()
    {
        return DBHelper.ExecuteSp("GetStudents");
    }
    public DataTable GetStudentById(int studentId) 
    {
        return DBHelper.ExecuteSp("GetStudentById", studentId);
    }
}

Only thing I could think of was that

A) Performance A slight increase (not sure of the specifics)

B) Readability StudentBll.GetStudents(); rather than

StudentBll studentBll = new StudentBll();
studentBll.GetStudents();

I wasn't too confident in those answers, however. Anyone care to enlighten me?

@TimSchmelter thanks, never used the tla for that (we just call it the business _layer_) meh, potato pahtahto — payo, Apr 30 '12 at 22:42
@白ジェームス: and you don't use any static ado.net objects(f.e. connections) in them? — Tim Schmelter, Apr 30 '12 at 22:43
@TimSchmelter - correct. connections/datareaders/etc are all contained within the DAL. — O.O, Apr 30 '12 at 23:27
@白ジェームス: Are they created in the methods or are they reused from somewhere? — Tim Schmelter, Apr 30 '12 at 23:31
@TimSchmelter - The DBHelper class is reused every place I need to call a stored procedure (see modified code above). It only contains methods that derive stored procedure parameters and logic to execute said stored procedure. — O.O, Apr 30 '12 at 23:35
@白ジェームス: As feared, does the `DBHelper` class reuse ado.net objects(especially a connection) or does it always create new instances with `using-statement` inside of these methods? This might be helpful: http://stackoverflow.com/questions/9705637/executereader-requires-an-open-and-available-connection-the-connections-curren/9707060#9707060 — Tim Schmelter, Apr 30 '12 at 23:42
@TimSchmelter - Oh, I see where you are going with this. Um, the call to ExecuteSp is always doing a try { connection.Open(); table.Load(someReader); } finally { connection.Close(); } — O.O, Apr 30 '12 at 23:50
@白ジェームス: You haven't still answered whether the connection is also static or not. To cut a long story short: if it's created in `ExecuteSp` everything is ok, apart from what Austin has said :) — Tim Schmelter, May 01 '12 at 00:03
@TimSchmelter - Ya, the connection is not static, just the method that creates it (ExecuteSp). Thanks Tim, you had me worried! — O.O, May 01 '12 at 00:06

Austin Salonen · Accepted Answer · 2012-04-30T22:32:04.597

3

With respect to performance, if you can't show what the increase is, then it does not support your claim. One could also argue that the performance gain by a static method call vs an instance method call is negligible to that of the round-trip travel & database time.

You've also locked down your implementation (or at least forced the consumers to do something harder to modify). If you lost the static methods and code to an interface, testers and developers of different tiers could build mocks so they wouldn't be forced to use whatever you provide them.

edited Apr 30 '12 at 22:32

answered Apr 30 '12 at 22:25

Austin Salonen

49,173
15
109
139

Austin - true, this was not designed for testing, as all tests in this case are integration tests with the sprocs. I see your points, however. – O.O May 01 '12 at 00:08

Sergey Berezovskiy · Answer 2 · 2012-04-30T22:37:37.977

2

Testability is the first thing that comes to my mind, when I see public static methods. Also forget about oop - no inheritance here (both classes and interfaces) thus you don't have class instances. No inheritance means no abstraction. No abstraction means tight coupling.

edited Apr 30 '12 at 22:37

answered Apr 30 '12 at 22:26

Sergey Berezovskiy

232,247
41
429
459

Static methods vs instance methods in BLL

2 Answers2