>>John,
>>About your second approach...
>>
>>So what you're saying is that I build my core components (NewsReader, Blog, ProductList, etc...) and have them each in a DLL. I would use reflection to load the DLL's. If a client wants to use NewsReaderOnSteroids instead of NewsReader, I would just develop the new component and deploy it in place of the existing DLL? I suppose I could use my config file to specify while DLL should get loaded for the component.
>>
>>I would think that this approach would lean heavily on implementing effective interfaces?
>
>
>That's true. If you want, I can send you some code snippets that we used. We allowed our clients to add custom code processing to an import process so that we didn't have to rewrite the entire load. The dll's were loaded on the fly using reflection and executed the customers code in the custom dll.

Interesting.

So here's my plan for a proof of concept:
I will create two interfaces: INewsletter and IJobPosting. These interfaces will have fairly basic structures: LoadData(), DisplayData(), ItemCount().

I will create two classes called Newsletter and JobPosting which subscribe to this interface.

I will create two more classes called BigNewsletter and BigJobPosting which also subscribe to this interface, but internally they have more data fields and their DisplayData function will return more data.

I will create a web front end that uses reflection to load the Newsletter and JobPosting assemblies using data stored in the web.config file. I will test that result.

I will then change the web.config file to point to the BigNewsletter and BigJobPosting assemblies. I will make sure that still works.

Does that sound reasonable?