I've been working with a friend on a project that we've taken over, and I've realized that we have a big problem implementing the model-view-controller design pattern due to the way that the project has been set up.
The project is currently split up into the following three sections (.proj files in Visual Studio):
- Model classes.
- Controller classes (business layer logic).
- View classes.
Visual Studio isn't letting me create cyclic references (quite understandbly) between two of these three sub-projects. This means that the controller classes can have a relationship with the view classes, but the view classes can't have a relationship with the controller classes! The result of this is that as soon as the controller displays a view, the rest of the controlling logic has to go in the view class!
So I've proposed that we merge all three sub-projects together (to avoid the cyclic references of visual studio). This means that we can create all the relationships between the three types of classes that the model-view-controller design paradigm requires. Ultimately, it will be we can place the controlling logic in the rightful place of the controllers, taking it out of the view classes.
The problem is I'm having a hard time convincing my friend about this. He thinks that having these separate boundaries between the sub-projects means that there's safety that we won't ever do things like put controlling or viewing code in the model (as the model sub-project is currently only ever referred to and doesn't refer to the controller or the view).
I was wondering if anyone could come up with some ways that I could really get my point across about how important this design pattern is, and how limiting it would be to go against it, and continue putting controller logic in the view classes?