Question

So I’ll try and play devil’s advocate on this one…

Hypothetically there is a Framework which services 2 or 3 different web sites. 1 basic function of the framework is to deal with all calls to a certain DB. When making a DB call the websites call a Framework DataSource object and get a generic Framework data object back.

Now for the websites to retrieve properties/methods that are specific to it’s needs we’ve got 2 solution options.

1. Create a new Class, extending or wrapping the generic data object,
   exposing more domain friendly properties & keeping any domain
   specific functionality inside of this new class.

2. Instead of creating a new class, create extension methods inside the Framework to service each of these websites. So everything is
   contained inside the Framework and can be shared between web sites
   if 1 day needed.

Just to clarify here would be examples:
Properties:

1. NewObject.GetSiteSpecificProperty
2. GenericObject.GetProperty(“GetSiteSpecificProperty”) or GenericObject.GetSiteSpecificProperty()

Methods

1. NewObject.DoSomethingSpecificToThisWebsite()
2. GenericObject.DoSomethingSpecificToThisWebsite()

So what solution would you opt for? 1 or 2?

Cheers.

Answer 1

In my opinion when designing a Framework you want to keep as much solution specific aspects out of the Framework and have the calling entities handle that if possible.

Now I’m not sure quite how your framework will be used or by how many different websites\projects but going with option (2) means that now whenever a new website is added the framework now needs to go do work in order to complete this functionality. The work of using the framework in a custom way should be handled by the websites not by the framework. If this framework ever grows to use 10 or even 100 websites, this becomes an absolute nightmare to maintain and your framework ends up looking much less like a framework and more like a solution specific product. Going with (1) is a much cleaner solution. Basically keep your framework reusable and solution-agnostic as possible.

If you are designing a framework that will be used by many different projects and is designed to be around for a while I’d recommend reading Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries (2nd Edition)