Conventions

Usually, in most web applications, conventions form around things such as:

• What controllers are named (i.e. HomeController for the /home URL)
• In which namespace(s) the controllers are located (i.e. MyProject.Web.Controllers...) and where they are located in the Visual Studio project structure and/or filesystem
• Where views, CSS, JavaScript files, images, etc are located on the file system
• The naming of views in relation to their action/url (i.e. /home/index goes to ~/Views/Home/Index.aspx on the ASP.NET  virtual file system)

FubuMVC encourages developers to establish these conventions for their own project and then define them using the FubuConventions class so that the rest of the application and even the framework itself may respect them.  This can give you great power as both the application and the framework can make safe assumptions about how things work in your environment and take shortcuts.

For example, after you have defined your conventions using the FubuConventions class, automatic discovery and configuration of controllers and actions becomes simple since controllers and actions can be mapped to their associated view (i.e. HomeController Index method would map to ~/Views/Home/Index.aspx) according to the conventions.  This lowers the amount of configuration "noise"  necessary as the framework can, conventionally, figure out how to wire up everything.

Controllers

In the MVC pattern in general, the "C"  is the controller. The controller's responsibility is ultimately to respond to user events and return a result to the user in some form.  This responsibility can involve numerous smaller actions which could eventually lead to a very fat, complex, and difficult to maintain class.  

To address this problem, the concept of a "controller"  is broken down into smaller modules which all act together to service the overall functionality required of the "controller".   Martin Fowler, in his book "Patterns of Enterprise Application Architecture" describes a particular strategy for this concept which he calls the "Front Controller Pattern."  FubuMVC uses a form of this pattern for its controllers.  This means that the entire functionality of the "controller" is accomplished in a number of different models both in the FubuMVC framework and in your code -- only a portion of which is contained in the actual controller class (i.e. HomeController).  The actual controller class implements the primary functionality of a given action. For example, for the URL "/tags/fubumvc" will ultimately execute the Index() method on the TagController. But before that method is executed, a number of elements of the framework, and potentially elements of your code, may execute. Likewise, after the action method has been called, more code may execute to add or override behavior.

For more information on code executing before and after the actuall controller action, see the discussion on "Behaviors" below.

Actions and OMIOMO

FubuMVC has a very strong opinion about how controller action methods should be structured.  This opinion is known as the "One Model In, One Model Out" concept (OMIOMO for short, pronounced om-yi-oh-mo; also known as the 'Thunderdome Principle' and 'Highlander Principle').  This means that controller action methods should be public methods that take in one strongly-typed model object and return one strongly-typed model object.  Dictionaries are strongly discouraged as they promote the use of "magic strings" which increase surprises, decrease visibility, and thwart compiler enforcement of data binding in the view.  By having strongly typed view models coming out of controller action methods, refactoring becomes easier and many mistakes don't happen in the first place which can speed up development in general.

Views and ViewModel

TODO

Behaviors

TODO

Dependency Satisfaction

TODO