how best to use .interfaces projects

Dec 5, 2008 at 8:18 PM

I'm using wcsf and entlib4.1 and am wondering how best to make use of the .interface projects being generated.  I guess I'm wondering why the guidance stuff isn't automatically doing some things (or if maybe it should NOT do some things).  See below.

1. So ideally any new foundation and business modules I create should have any generated or created interface code moved to the .interfaces projects right?  Would this include the generated code for the module initializer and the controller stuff?  I guess I thought guidance would do this for me.

2. For my foundation and business modules, their references should only include references to interface projects for best de-coupling - correct?

3. For any classes shared across multiple modules, I should break those classes out into a 'shared' module with an interface for best design - correct?

4. In the website project itself, why does guidance add references to the implementation projects rather than the interface projects?  Ideally shouldn't this be only interface stuff?

5. Stupid interface coding question.  Given the code below (taken from some great blogs), I know that Location would be part of the interface definition.  But how do I make the static readonly items available?  What would go in the interface and what would go in the implementation?

Thx

using System;
using System.Collections.Generic;
using System.Text;

namespace SampleApp1.Navigation
{
    public class Screen
    {
        private Screen(string location)
        {
            _location = location;
        }

        private string _location;

        public string Location
        {
            get { return _location; }
        }

        public static readonly Screen Home = new Screen("~/Default.aspx");
        public static readonly Screen Reports = new Screen("~/Reports/Default.aspx");
        /* ...etc... */
    }

}

Dec 5, 2008 at 11:18 PM
In thinking through this more, I'm getting myself confused.

So to REALLY de-couple, don't I have to take a factory approach?

I mean, if I only reference an interface and not the actual implementation class as well, then I can't do something like this:
using App.MyClass.Interface;
...
IMyClass theclass = new MyClass();
because I don't know anything about MyClass.

But I sure don't want to know anything about MyClass internals if I can help it.  Better de-coupling, less referencing, etc.

So, wouldn't I have to create some kind of class factory that would return an IMyClass object for me?
The factory might have a static class in it that did something like:
using App.MyClass.Interface;
using App.MyClass;
...
IMyClass BuildMyClass()
{
    return new MyClass();
}

...then the original code above would do this:
IMyClass theclass = Factory.BuildMyClass();

Correct?  Overkill?

Thx