Interfaces on Business Modules

Topics: Web Client Software Factory, UIP Application Block discussion, User Forum
May 13, 2008 at 1:12 AM
Hi,

When I use the recipe to create a new Business Module and check the "interface" option I get projects like
<BusinessModule>
<BusinessModule>.Interface


But always, the <BusinessModule>.Interface project is empty. Even the interfaces in the business modules are not placed in the <BusinessModule>.Interface project. Why is that so? What is the purpose of creating this interface project?

Any pointers?

I assumed that the View will have CPresenter<Iinterface> myPresenter reference by using the Interface project, but the view actually holds a concrete ref to the C<blah>Presenter class.. So not sure about the inteface project.



Regards,
rasane
May 13, 2008 at 4:38 AM
Edited May 13, 2008 at 4:40 AM

rasane_s wrote:
So not sure about the inteface project.
Consider the following code where my BusinessModule1 has an Interface as well as a class that implements it - the class utilizes a class in FoundationModule1:

namespace BusinessModule1
{
    Interface IMyClass
    {
        string HelloWorld();
    }

    public class MyClass : IMyClass
    {
       public string HelloWorld()
        {
            // This will require a reference to FoundationModule1
            UseFulUtility uu = new UseFulUtility();

            // Get the ReturnWorld value and append to hello
            return string.format("Hello {0}", uu.ReturnWorld());
        }
    }
}

FoundationModule1 is happy but then a new requirement arises (ReuseHelloWorld) that would have us implement IMyClass in BusinessModule1 - we have a problem because BusinessModule1 references FoundationModule1 (for UseFulUtility).   We either have to copy the IMyClass interface into this project -or- refactor code to make it work.

namespace FoundationModule1
{
    public class UseFulUtility
    {
        public string ReturnWorld() { return "World"; }
    }

    // The following class would require a reference to
    // BusinessModule1 which is illegal because BusinessModule1
    // already has a reference to this module for UseFulUtility.
    public class ReuseHelloWorld : IMyClass 
    {
         // Circular reference error trying to add BusinessModule1 to access IMyClass
    }
}
}}

The solution is to put your interfaces in a separate project, i.e., <BusinessModule>.Interface, and have both BusinessModule1 and FoundationModule1 reference it.

 

 

 


May 13, 2008 at 6:29 AM
Cool BillKrat. Thanks for answering the part of my question about: "what is the purpose of <BusinessModule>.Interface".

The explanation you give was my suspicion too, but when I use the recipe to create a business module, it does not automatically put the interface classes it builds in to the interface project. This is what confused me. So now from your answer I understand that the interface classes should be put in to the <BusinessModule>.Interface project- in my example that would mean
  • I<BusinessModule>Controller
  • I<ViewName>View (many of this, as many views)

I understand that the value is really when there is a possibility of circular reference, which in my case is not happening yet, but sounds like the best practice answer when I construct using the recipe with a Interface project, should have put the interfaces in the interface project. Please reply if the above understanding is incorrect.

The second part of my question is why does the View hold a reference to a concrete Presenter class? The more i think of it, right now it sounds academic.

May 14, 2008 at 4:35 AM


rasane_s wrote:

I understand that the value is really when there is a possibility of circular reference, which in my case is not happening yet, but sounds like the best practice answer when I construct using the recipe with a Interface project, should have put the interfaces in the interface project. Please reply if the above understanding is incorrect.

The second part of my question is why does the View hold a reference to a concrete Presenter class? The more i think of it, right now it sounds academic.



[rasane_s] "Should have put the interfaces in the interface project"

Careful consideration needs to be put into what you put in your <businessModule>.Interface - otherwise (as the program grows) you can be locked out of a required reference because of the circular reference issue...

Take for example the View interface - in MVP the presenter does not communicate directly with the View; it can only access it via the interface.   So if you have a user control declaration in your interface, e.g.,  MyUserControl MyControl {get; set; } you will have to have a reference to the assembly that holds MyUserControl.   If you moved the View's interface into the <businessModule>.Interface it would have to have a reference to the assembly that held MyUserControl - now that assembly (and all of it's classes) will not be able to reference any of the interfaces in <businessModule>.Interface.

[rasane_s] "The second part of my question is why does the View hold a reference to a concrete Presenter class? "

Can't say I have read (or seen) a P&P response to that question (perhaps someone else my offer some insight); my opinion would be to prevent an additional (unnecessary) layer of complexity since the View is allowed to talk to the presenter (MVP).