Static or instance methods in Data Access Layer
-
Hi, I've been wondering about this for a long time, so I decided to post this question here to get some opinions. Suppose I have a Data Access Layer (DAL) with a CustomerData object. This CustomerData object has a GetCustomers() method which returns a DataSet (or a CustomerDataSet typed data set.) Assuming this method is entirely stateless (no member data accessed), which it really should be in a DAL, is it considered best practice to make this a static method or an instance method. I like the idea of a static method, so I can code: DataSet myCustomers = CustomerData.GetCustomers(); instead of CustomerData myCustomerData = new CustomerData(); DataSet myCustomers = CustomerData.GetCustomers(); Since there is never any instance data, I don't really see the use in using an instance of this class. However, I am sure their are other things to consider here, so I am looking forward to your feedback on this. Roel
-
Hi, I've been wondering about this for a long time, so I decided to post this question here to get some opinions. Suppose I have a Data Access Layer (DAL) with a CustomerData object. This CustomerData object has a GetCustomers() method which returns a DataSet (or a CustomerDataSet typed data set.) Assuming this method is entirely stateless (no member data accessed), which it really should be in a DAL, is it considered best practice to make this a static method or an instance method. I like the idea of a static method, so I can code: DataSet myCustomers = CustomerData.GetCustomers(); instead of CustomerData myCustomerData = new CustomerData(); DataSet myCustomers = CustomerData.GetCustomers(); Since there is never any instance data, I don't really see the use in using an instance of this class. However, I am sure their are other things to consider here, so I am looking forward to your feedback on this. Roel
I don't think this is a good approach. Why not making your entire application static then? If you instanciate objects, you can clean them up neatly if not required. Your database connection object needs to be static which I experienced lots of problems with (for example using threads). I think there are multiple reasons not to make such functions static, but make you instanciate the class they're in ;-) Removing HTML code from a string or such functions are more qualified to be static
.: I love it when a plan comes together :. http://www.zonderpunt.nl
-
I don't think this is a good approach. Why not making your entire application static then? If you instanciate objects, you can clean them up neatly if not required. Your database connection object needs to be static which I experienced lots of problems with (for example using threads). I think there are multiple reasons not to make such functions static, but make you instanciate the class they're in ;-) Removing HTML code from a string or such functions are more qualified to be static
.: I love it when a plan comes together :. http://www.zonderpunt.nl
Database connection does not necessarily have to be static, it all depends how you write the code. I am using Enterprise Library now... Database db = DatabaseFactory.CreateDatabase(); using (DbCommand dbCommand = db.GetStoredProcCommand("GetAccount")) { etc...