0

I have a desktop instrumentation application in MVC. Currently I had 2 versions of the application, thus 2 views and 2 controllers, each having common code in a base class. The views react directly to events sent by the model, and the controller has a message queue for linking user actions to the model. Notably the message queue is common to the two controllers.

In these two versions the UI logic is very simple, it's mainly reacting to buttons, passing parameters to the controller, and . In the next version I have some workflow tasks, so the UI will get more complex.

I also want the initial versions to be still functional.

Where do I put this complexity? Should I add another message loop that is in-between? Will it belong to the controller or the view? Where should I put the state of my workflow? Or should I build an intelligent view?

  • This answer helped me to understand that separation must be done between domain layer and application layer (what I call "workflow" in my question) – CharlesB Apr 12 '11 at 18:09
1

MVC is a very basic architecture. You have a Model - View - Controller. You still need to create your own layers to support MVC, like BL/DL, service layer, helper methods, whatever the design requires.

The controller is the first entry point. So, I recommend you make the calls to other layers in the controller

MyViewController()
{
  ServiceLayer serviceLayerCalls = new ServiceLayer();
  BusinessLayer businessLayerCalls = new BusinessLayer();

  businessLayerCalls.Method()...etc

  return MyView();
}

Its ok to have some code in the view, but try to make sure it fully belongs there (E.G. an html helper). Wrap up long routines in methods.

  • Thanks for your answer; so I might have another class for maintaining workflow state. My question might be reformulated to "is it wrong to put workflow logic in the View". Will get back when my mind is ready to reformulate :) – CharlesB Apr 12 '11 at 17:49
  • @CharlesB - Perhaps a rephrase would help. As far as "is it wrong to put workflow logic in the view", yes it is. If by "workflow" you mean page routing, that belongs in the route engine. Consider creating custom routes over custom workflow in this case. Depending on your need, this may remove the need for a custom workflow entirely. See ScottGu's blog for more info weblogs.asp.net/scottgu/archive/2007/12/03/… – P.Brian.Mackey Apr 12 '11 at 18:48
  • Just a side note, it's no webapp here, but plain desktop software (instrumentation software, written on labview) – CharlesB Apr 12 '11 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.