Confusion between view logic and domain logic in a ASP.NET MVC Web Application

Question

I am getting confused between domain/application logic and User Interface logic. To illustrate what I am trying to nail down, I will describe an imaginary program below for illustration purposes:

(1) Imagine a small application with a set of 3 cascading drop-downs. As you select one dropdown it triggers a jQuery Ajax GET which ends up hitting a MVC controller, supplying the selected value of the previously selected drop-down. The controller returns the allowable choices for the next drop-down. The javacript (in the view) arranges these results into a drop-down. and so on. So each time you select a drop-down, the next one gets populated.

(2) Now throwing in a wrench.. There are some exceptions. Lets say if the user selects "FOO" or "BAR" in the first dropdown, then the behavor changes, so that the second dropdown is disabled, and the thrid dropdown will show a texbox instead.

My questions is, in the context of MVC, what is the appropriate place for this "decision" logic? Such as the code that is responsible for making these decisions like I explained in (2). The most convenient place that I have been putting this was right in the javascript of the view. I simply wrote javascript to test if the first box is "FOO" or "BAR" then, disable the second dropwdown, and swap out the third dropdown for a textbox. But this does not feel quite right to me. Because It seems like it should be business logic therefore the code should belong in a domain layer some place. But that does not feel quite right either.

And so I feel like I am going in circles. Can some one shed some light on this little design?

Answer 1

Let's start at the Domain Model. A Domain Model is an API the models the Domain in technology-neutral ways. It knows nothing about View technologies such as JQuery, HTML or (for that matter) XAML or Windows Forms.

The Domain Model contains classes and interfaces that describe the Domain and lets you model the Domain Concepts in a rich and expressive way - no matter what type of application you are developing.

With that in mind, it's fairly easy to see that the display logic you describe doesn't belong in the Domain Model. It must, therefore, belong in a UI-specific layer.

You can put that in a separate UI Logic module or together with your UI application - in your case an ASP.NET MVC application. Whether you express the desired UI logic in JavaScript or server-side is less important.

Personally, I would define this logic server-side in Partial Views, but that's because I care a lot about testability, and I know how I would unit test such behavior (I've been told it's possible to unit test JQuery code as well, but I have no idea whether that's true or not).

If you ever end up writing another application based on the same Domain Model, it is very likely that the display logic turns out to be very different, because different technologies imply different paradigms.