PetShop 3.0. Design patterns????
Recently my MSDN RSS feed announced me new version of .NET PetShop. The article tells us that PetShop was refactored for better architecture.
I was so curious, that I have downloaded PetShop installer and gave it a try. I am rather disappointed with its architecture. I am not telling that PetShop's architecture is bad. IMHO architecture can not be good or bad, but it may suite several requirements better or worse.
Current PetShop implements every type from conceptual model with the use of six classes from six projects (BLL, DALFactory, IDAL, Model, OracleDAL, SQLServerDAL).
I think you can estimate the cost of change in domain field. If you change one type, you will be obliged to change six classes.
You can also estimate the amount of work, which is required to add additional database layer. To add additional database you need to create NewDBDAL from the scratch, and you also need to extend DALFactory.
There are different ways to map relational data to objects. PetShop v3.0 is using Table Data Gateway. This at least doubles amount of classes, required to implement any domain field type. This is not good or bad, let's take it as a fact. How could we refactor current app and make it more extensible still using this pattern?
I would advise using Bridge pattern and implement DAL classes as one class instead of two classes and one abstract interface. This way we could separate DAL interfaces and algorithms from concrete database implementations. Later, when we decide to add support for additional DB we won't be rewriting DAL from the scratch we will just add additional implementation. We will also be able to reuse those implementations in our future projects, while current DAL has nothing to reuse if the project is not related with PetShop.
Another issue is BLL/Model. What's the benifit of splitting every class into two ones, one for behaviour and another for data?
Unit tests.... If this application is considered to be a good learning example, I think it should include unit tests at least for the business logic.