arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down RSS star Twitter twitter GitHub white-balance-sunny window-close
Opinions: View() or Window()/Page()?
1 min read

Opinions: View() or Window()/Page()?

This is an old post and doesn't necessarily reflect my current thinking on a topic, and some links or images may not work. The text is preserved here for posterity.

I am after opinions on an API change to Magellan.

When you write actions on a controller, you can return a ViewResult with the name of the view you want to show. For example:

public ActionResult Show(int customerId)
    var customer = repository.GetCustomer(customerId);
    Model = new CustomerDetailsModel(customerId);
    return View("CustomerDetails");

Magellan will then invoke a list of View Engines to track down the view. For example, it will look for:

  • CustomerDetails.xaml
  • CustomerDetailsWindow.xaml
  • CustomerDetailsPage.xaml
  • CustomerDetailsView.xaml

When it finds a match, it will use the view type to "render" the view. Windows will be shown via Window.Show(), pages will be navigated to via the NavigationService, and so on.

What this means from the Controllers point of view however is that the controller action can't be sure what kind of view will get shown; and therefore can't (easily) add view-specific arguments. For example, with a Window, it would be nice to state whether the Window should be shown as a modal dialog or as a non-modal window.

Now, the ViewResult class does store a dictionary of custom parameters that the view engines can use. So this means extension methods can easily be used to specify the settings above. For example:

return View("CustomerDetails").AsDialog();

What I don't like about this is we're mixing the generic concept of a view, with the specific concept of a dialog. Which makes the first kind of useless. So I'm considering changing the API's to use more specific results:

return Window("CustomerDetails");
return Dialog("CustomerDetails");
return Page("CustomerDetails");

Unit testing the controllers will be just as easy as they currently are, but it should make the controllers a little less ambiguous. What do you think?

Update: based on feedback I have gone with the seperate return actions instead of just View(). You'll find this in the latest build.

Paul Stovell's Blog

Hello, I'm Paul Stovell

I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.

I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.