I am working on an application design that requires two projects to cross reference each other.
I found the excellent Formfactory / Interface example/solution (listed below) on this forum.
Unfortunately I am not C# literate. I understand and appreciate the method, but my attempt to convert it into vb2005.net has been defeated by the C# syntax.
I would greatly appreciate someone (multilingual) providing a translation into vb2005.net
Here is the C# solution:
The pattern to solve this is abstract class factory, together with the singleton pattern.
What you have to do is the make a classfactory for the forms. This classfactory you can place in your main program, which anyway MUST reference your assemblies, thus it will know about your forms.
Place the following code in a seperate project - call it interfaces. Let your main program, your form1 and your form2 assemblies reference this interface project.
The content is as follows:
interface IFormFactory { IForm CreateForm1(); IForm CreateForm2(); } interface IForm { void ShowForm(); } // and the singleton is as follows (in the same interface project!) public class Singleton { static private IFormFactory _instance; static public IFormFactory Formfactory { get { return _instance; } set { _instance = value; } } }Note that this interface will have some information about the number of forms you need, but you can make this interface any way you want.
In your main program you implement the concrete factories (could also be implemented as seperate factories together with the forms, but that is a further refinement 
.
Place the following code within your main method in the program class, before you start up any forms.
Singleton.Formfactory = new FormFactory();
and add the following class to the same main project
class FormFactory : IFormFactory { public IForm CreateForm1() { return new Form1(); } public IForm CreateForm2() { return new Form2(); } }Now: In each of your Form assemblies, reference the Interface project, and let the Form class inherit IForm, implement the ShowForm method as:
void IForm.ShowForm() { Show(); }Now, lets say you're in Form1 and you want to start up Form2. You do this by using the following code, f.e. as response to a button for starting that second form:
IForm form2 = Singleton.Formfactory.CreateForm2(); form2.ShowForm();The first line gets the factory from the singleton and creates a new form of that type, the second line starts up and shows the form. If you need more methods for accessing the form from the outside, just add them to the general interface IForm.
Help required to solve circular dependency problem in vb2005
Angel David Lara
jcarlos.net
To OmegaMan and Peter Roth,
Thanks for the philosophical analysis. I agree, and have adjusted my approach. (But if we were all content with existing methodologies, nothing would improve!!)
danadanny
programmer01
Thanks OmegaMan, I am following your advice and experimenting with interfaces, singletons and form factories, but I am also following your second suggestion and have merged the two projects into one assembly. This is a short term solution and I need to separate them again in the future.
I understand and agree with the need to resolve circular dependencies, but I am dissapointed that Microsoft have not provided a better solution to this problem in Visual Studio 2005.
The argument that circular dependencies are simply bad architecture is outdated. I work with a company that is developing and supporting ERP software. A practical design approach for building an interactive modular application is to create a multi-project solution, (with each project a departmental module).
ERP is big software, our current version has 539 forms, more reports and thousands of SQL stored procedures. One of the key benefits of ERP software is that users can get the 'big picture' on an enquiry by drilling down into multiple departmental modules to track all related elements. For example an enquiry initiated from a form in the General Ledger module may open forms in the Inventory and Warehouse modules
At a programming level this means constant inter-module navigation. Circular dependency should not be an exception to be handled in a clumsy, laborious, out-dated, maintenance intensive combination of factories, singletons, and interfaces. The problem is in limitations in the build, there should be a simple, efficient tool that creates the bypass. Perhaps Interface version 2.
This may be an after-market opportunity, but I would have liked to see a fix from Microsoft who, (from what I have read on these forums), seem to have its collective head in the sand on circular dependencies.
Does any forum reader have a better solution to circular dependency
Devin
Jim – sorry to be the bearer of bad news, but it’s like in many engineering situations: “if only we didn’t have A, this B would C!” Substitute A=”gravity”, B=”rock”, C=”fly” to concretize the image. Another more pertinent substitution is provided in the case at hand where A=”a problem with circularity”, B=”this program”, C=”would run”.
canadian_coder
The tack taken was to see if one could do a specific language methodology and apply it to C#. I, as well as others that come to C# from different languages and try/have tried to do this for our favorite pet methodology have also come up empty handed. (I always loved dynamically setting up a list of pointers to functions and being able to non sequentially execute them...sigh). But it is not the C# way of doing things. C# can be used for Object Oriented programming, but hey its no SmallTalk either
To fully use any language one has to work within its methodology. The methodology presented in the posts is not C#. A work around was mentioned and yes, that is what it is; a work around the C# methodology. I would bet that if the same task objectives were handed to a seasoned C# developer a work around would not be done, but a properly architected response using the true design goals of the language would be used and it would shine.I leave you with this analogy, “A Ferrari may be fast, but you don’t take it to a drag strip.”
Abhishekbhadouria
If you are beholden to the above design, here is someting that might help you converting the items which I found this helpful when I needed to go between the langues, VB.Net and C# Comparison otherwise the Microsoft VB Reference is a good place to look.
I recommend that you create a factory model that doesn't get so hung up on window's forms and what not...just try to reproduce the basic pattern in a side project, to get you up to speed. Once you learn about the pattern, placing in the hard stuff will be a lot easier from what you learned in the scratch project.