another break with the Onion Architecture

In the onion approach one should be motivated to push as much logic into the core as possible, without bringing in external dependencies, making it at fat as possible. One should loathe to keep logic in the UI, where it has been traditionally hard to test. However, the UI testing is getting easier, especially with the way now that modern StructureMap hydrates dependencies at MVC4 constructors for controllers and at my work we have found another reason (see this for the first) to break with the traditional onion framework. If, in a workflow, different steps may throw different exceptions or cause different here-is-what-happened messaging to come back out of a controller, it is probably cleanest to have this logic in a controller and to just wrap the controller in test. The alternative to keep the logic in the core and have it bubble up a core object to the controller where there has to be a new rat's nest of logic to cast the core object to the here-is-what-happened UI messaging type. The controllers are easier to test now. One may stub or mock the dependencies at the constructor's signature. It is trickier to deal with Session. It probably needs to be brought in to scope as one of the dependencies.