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

In that situation where you have very specialized actions happening you need to put it in the logic in the js like you have been doing in your drop down example. You will also always want to put the validation on the server side as well to ensure your data is clean.

With the MVC 2 stuff coming out they have some really great validation server/client side validation going on. Check out Scott Gu's post more insight on this: MVC 2 Blog Post

Answer 2

Without splitting too many hairs or getting too fanatical on WHAT MUST BE DONE TO KEEP THE PATTERN PURE...

Obviously the Controller knows that this change must occur, as it will be handling both resulting cases (drop down selections or text entry). So putting logic relating to this in the Controller is not a sin.

It is also equally as obvious that the View must change how it displays depending on the contents of the first dropdown. While this mixing of behaviors isn't exactly the best UI experience I could imagine, if requirements must, then the logic for this must exist to some extent in the UI. But, jeez guys, this is a website we're talking about here. Do you really want to remove all logic from javascript and move it into a controller method? The View is deciding on how to display data, which is its job, and so cannot be a sin.

The real way to avoid getting burnt at the stake is to redesign to avoid the controversy in the first place. Or, just code it and bitch about your lousy design requirements over a beer.

Answer 3

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.

Answer 4

Given your example I wouldn't mind this logic in the controller, it definitly doesn't belong in the domain model. I would personally feel better grabbing the ajax GET request in the controller and deciding what to output from there with JSON instead of doing all that logic in jQuery (I just feel more comfortable in C# then in javascript). With that being said, I like to keep my action methods skinny so what I would do is put the logic involved with figuring out what to populate the dropdowns in a method on the conroller and decorate it with [NonAction].