How to initialize a class?

Question

The problem is really simple: I have a "Stock" class, I want to load its "StockName", "StockCode" property from db.

which patten should i use?

pattern 1) Use the service class to create it

public interface IStockService{ Stock GetStock(string stockCode); void SaveStock(Stock stock); } public class StockService : IStockService{ } IStockService stockService = new StockService(); Stock stock = stockService.GetStock(); 

pattern 2) Use the static method in stock

 public class Stock{ public static Stock GetStock(){ Stock stock = new Stock; //load stock from db and do mapping. return stock; } public void Save(){ } } 

pattern 3) Use constructor to load

  public class Stock{ public Stock(){ //load stock from db and do mapping. this.stockName = ... this.stockCode = ... } } 

for template 1: it seems that it uses so much code to create a stock object, and the "SaveStock" method looks a bit non-object oriented.
for template 2: the "Save" method looks fine, but the GetStock method is a static method, it seems that the Utility class always uses a static method.
for template 3: the constructor will load data from db during initialization. it is also embarrassing.

Answer 1

pattern 2) is a factory (method) patten and reminds me of singleton (static = singleton). Note singletons are evil . The factory method is not polymorphic. You cannot change it for tests (i.e. you cannot mock it). This evil! Avoid this!

pattern 3) violates the constructor, which should not do too much. Querying the database is too difficult for ctor, in my opinion. An object and its creation are different problems and should be separated. Further instance creation should be separated from the instance, so try using factories (or injectors). You can replace the factory easier than the "new class" distributed by your code.

pattern 1) remains what is an abstract factory pattern. It's good. You can use another implementation for testing (layout). It separates the creature from the object. (The principle of shared responsibility, as Karl Bergquist calls it).

So, I would go with template 1.

Answer 2

Sample 1:
- easier to test
- The principle of shared responsibility
- More code may be required.

Sample 2:
Static classes / methods can complicate the process. I try to avoid it as much as possible.

Figure 3:
- Good for small classes. But keep the logic from the constructor

But I think that Orm and serialization cover most of the parts (creating objects).

Answer 3

You are missing the important part. In particular, where do you get the connection string to talk to the database?

Update each of your examples where the connection string comes from, and I think that it will choose the correct answer.

Answer 4

something similar to method 1 where you have to call DB class classes to get the object loaded from there, although you can use ORM to take care of all the data access for you

Answer 5

Personally, I like that my objects are abstracted from the data source, so I would go with a method like # 1. # 3, you definitely do not want to do ... too much processing in the constructors can cause you problems. Preference # 1 versus # 2 probably comes down to how to “load” you want your data objects to be.

If you ever anticipated getting your object from another data source, you might want to stick with # 1, as it provides much better flexibility.

Answer 6

I would go with template 1. It is a clear separation of problems between the domain model and data access. It is also simpler unit test.

Answer 7

if you want it to be automatically initialized, use the static constructor that was called by the .net class loader service.

Answer 8

you must separate the entity class (stock) and the logic that fills it (storeservice), but instead of writing the storeservice class, simply use orm to map the db to the entity class (stock).