CODEWITHSUNDEEP
c#wpfdesign-patterns
user337816
user337816

Reputation: 375

Design Layout/Patterns

I am still fairly new to C# and I am trying to decide the best way to structure a new program. Here is what I want to do and I would like feed back on my idea.

What I am struggling with is if it is ok to have the classes in the Data Layer and Business Layer inherit from the types I define in Model Layer. This way I can extended the types as needed in my Business Layer with any new properties I see fit. I might not use every property from the Model type in my Business Layer class but is that really a big deal? If this isn't clear enough I can try and put together an example.

Upvotes: 0

Views: 351

Answers (3)

Phil
Phil

Reputation: 2715

I think an example would be good - I don't think what you're suggesting is necessarily bad, but it depends on what you're trying to achieve.

Why are you inheriting from classes in your model layer? What is the interface and purpose of the specific model classes, and what is the purpose of the business logic classes which are inheriting from your model classes?

Does inheritance really make sense?

Would inheritance violate Liskov's substitution principle?

EDIT:

wpfwannabe, I would be careful about using inheritance just because it seems to be the easy option. I specifically mentioned the Liskov substitution principle because it deals with determining when inheritance is valid.

In addition, you may also want to look at the 'SOLID' design principles for OO development (which includes Liskov's substitution principle):

http://en.wikipedia.org/wiki/Solid_(object-oriented_design)

Upvotes: 0

Kevin Le - Khnle
Kevin Le - Khnle

Reputation: 10857

Whether to put the classes of each layer in a separate library depends on if you would need to write more applications in the future that would need to use these same classes. You might think that you need and start doing right away. From my experience, I start to have better ideas after coding and having at least some kind of proof of concept. Organizing code, such as re-factoring, organizing into libraries, etc at some point during the middle of the project is easy. It's trying to do that right before going live which is risky and not a good idea.

Regarding the remaining parts of your question, I would refer to you what I learned from Martin Fowler as I can't say better than him and if I do, I am just repeating after him:

http://martinfowler.com/eaaCatalog/serviceLayer.html
http://martinfowler.com/eaaCatalog/

Upvotes: 0

Adam Robinson
Adam Robinson

Reputation: 185593

The general practice is to use encapsulation, not inheritance, for layer transitions. Consider the following two paradigms (if I understand you correctly)

Model/Data Layer:
    Customer
    Order

Business Layer:
    MyCustomer : Customer
    MyOrder : Order

versus

Model/Data Layer:
    Customer
    Order

Business Layer:
    MyCustomer (encapsulates Data.Customer)
    MyOrder (encapsulates Data.Order)

There are two main issues when going the first (inheritance) route:

  1. When you modify the base (data/model) class, you're forced to change the business class.
  2. Getting object relationships is difficult and generally requires a non-polymorphic approach. I.E., if the model or data layer exposes a collection of Orders on a Customer object, it's difficult and "kludgy" to get your MyCustomer class to expose a collection of MyOrder objects instead.

Utilizing encapsulation deals with both of these issues, and is definitely the route I'd recommend.

Judging by your name, I'm assuming you're looking to write a WPF application. If that's the case, look into the Model-View-ViewModel (MVVM) design pattern.

Upvotes: 5

Related Questions