I'm working an application, it's a .net 4 web application which communicates with a WCF service. The WCF service calls The Business Layer classes, which then call the Data Access Layer. Currently the BL and DAL layers are public classes, but the method
in them are all static. Just wanted to see if that's ok, or should they be non static and working with class instances instead? For example, I have a BL class like this:
public class Donor
{
public static bool IsDonor(int empId)
{
return DAL.DonorProvider.IsDonor(empId);
}
}
and then the DAL would be:
public class DonorProvider
{
public static bool IsDonor(int empId)
{
// do database work and return a bool
}
}
is this common, ok to do? Or should I have it so that the BL layer, makes an instance of the DAL layer, so the methods are then non static?
One of the downsides of using static methods is that it becomes harder to test, i.e. you can't replace your dependencies with mocks. Another one is that you can get concurrency problems when using static methods.
The overhead of creating and destructing instances of classes is usually so small that it's not a reason for using static methods.
Currently the BL and DAL layers are public classes, but the method in them are all static. Just wanted to see if that's ok, or should they be non static and working with class instances instead?
When using 'Shared' or 'Static' methods, you are declaring that the methods are accessible by all objects and not by just a single instance. The problem with Shared methods is they do not lend themselves to Object Oriented Programming and lay more along
the lines of Procedural Programming as they do not allow encapsulation of state and behavior. These concepts are important when you need to have multiple unique instances of the same object. Think of a 'Employee' class with (2) properties: FirstName and LastName.
Each instance is going to have its own unique values and state, and this is needed once you pass the bounds of very simple programming techniques. Static/Shared methods also do not lend themselves to unit testing either.
I typically don't expose 'Shared' (VB.NET) or 'Static' (C#) methods Publically between layers too often, but they are not totally taboo, as they work well for 'Helper' or 'Utility' methods (i.e. Public Shared Function AddValues(i1,i2) As Integer) that do
not modify any internal or global state and will return the same result given identical input. If I am using Shared methods, I expose them within that layer to be accessed in that manner. So I am not usually calling Static or Shared methods on the BLL from
the UI or obviously the other way around. However sometimes I will have a 'Utilities' class within the UI or BLL marked as 'Friend' (or internal C#) so they are fully accessible within that layer. Another way to expose them is via a vertical Infrastructure
layer as well.
To wrap it up, I would not just mark everything as 'static'. Use static when it is
appropriate and needed and as a rule of thumb, always use the lowest visible access modifier when decorating classes and methods and only elevate as needed.
pdassnyc
Member
221 Points
228 Posts
static methods vs non static in Data and Business layer
May 04, 2012 06:01 PM|LINK
Hi,
I'm working an application, it's a .net 4 web application which communicates with a WCF service. The WCF service calls The Business Layer classes, which then call the Data Access Layer. Currently the BL and DAL layers are public classes, but the method in them are all static. Just wanted to see if that's ok, or should they be non static and working with class instances instead? For example, I have a BL class like this:
public class Donor { public static bool IsDonor(int empId) { return DAL.DonorProvider.IsDonor(empId); } }and then the DAL would be:
public class DonorProvider { public static bool IsDonor(int empId) { // do database work and return a bool } }is this common, ok to do? Or should I have it so that the BL layer, makes an instance of the DAL layer, so the methods are then non static?
Thanks.
mm10
Contributor
6445 Points
1187 Posts
Re: static methods vs non static in Data and Business layer
May 05, 2012 09:33 AM|LINK
One of the downsides of using static methods is that it becomes harder to test, i.e. you can't replace your dependencies with mocks. Another one is that you can get concurrency problems when using static methods.
The overhead of creating and destructing instances of classes is usually so small that it's not a reason for using static methods.
atconway
All-Star
16846 Points
2756 Posts
Re: static methods vs non static in Data and Business layer
May 08, 2012 07:50 PM|LINK
When using 'Shared' or 'Static' methods, you are declaring that the methods are accessible by all objects and not by just a single instance. The problem with Shared methods is they do not lend themselves to Object Oriented Programming and lay more along the lines of Procedural Programming as they do not allow encapsulation of state and behavior. These concepts are important when you need to have multiple unique instances of the same object. Think of a 'Employee' class with (2) properties: FirstName and LastName. Each instance is going to have its own unique values and state, and this is needed once you pass the bounds of very simple programming techniques. Static/Shared methods also do not lend themselves to unit testing either.
I typically don't expose 'Shared' (VB.NET) or 'Static' (C#) methods Publically between layers too often, but they are not totally taboo, as they work well for 'Helper' or 'Utility' methods (i.e. Public Shared Function AddValues(i1,i2) As Integer) that do not modify any internal or global state and will return the same result given identical input. If I am using Shared methods, I expose them within that layer to be accessed in that manner. So I am not usually calling Static or Shared methods on the BLL from the UI or obviously the other way around. However sometimes I will have a 'Utilities' class within the UI or BLL marked as 'Friend' (or internal C#) so they are fully accessible within that layer. Another way to expose them is via a vertical Infrastructure layer as well.
To wrap it up, I would not just mark everything as 'static'. Use static when it is appropriate and needed and as a rule of thumb, always use the lowest visible access modifier when decorating classes and methods and only elevate as needed.