Controllers - model vs. use case centric

I am working on a reasonably large application (which happens to be my
first with rails).

I was hoping to get some input on organisation of controllers and
actions.

I am finding having used scaffolding more at the beginning my
controllers tend to be very model centric, in that they mostly contain
all the actions for management of that particular model, which may crash
across multiple use cases. I find this effective in the sense it keeps
related actions together. However I am wondering whether it makes more
sense to split more administrative actions out into a separate
controllers?

I imagine this could be a matter of style, experienced MVC developers
mixing the two. However any comments on the people’s experience would be
much appreciated.


I also have a question regarding menu pages, I have many maintenance
actions that I wish to group into a section of the application. I was
thinking of having something like DashboardController with actions such
as ‘maintenance’, ‘warehouse’, ‘accounts’ etc. These would contain views
with links to major controllers and actions specific to that area of
work.

This seems reasonably ‘tidy’, however has anyone tackled it differently?

Thanks, Andrew.

I usually mix it up for relatively larger projects, with more preference
to
use case centric. When authentication and authorization is implemented,
it’s
much easier to put all related secure actions into one controller
instead of
having them scattered throughout the different unrelated ones. Still,
this
is based on instinct and I don’t have a formal decision process for it.
I’d
like to hear what others do too.

“Andrew E.” [email protected] wrote in
message news:[email protected]

It seems that DHH is tackling this question, with his new proposal to
orient everything around C/R/U/D.

There’s a fundamental ambiguity here: What does a controller do? The
answer right now, in Rails, is: “not much”. It’s just a way of grouping
a bunch of actions, for convenience. Although it’s technically called a
class, it doesn’t have any of the class like things that normally make
classes classes: invariants, shared private data / information hiding,
encapsulation, single responsibility.

Hence, it’s really never clear the “right” place to put actions, and how
to group controllers.

I think the Rails community would benefit from looking again at
classical OO strategies. The responds_to |wants| block/switch,
despiting all the raving about it, is exactly the type of thing that
inheritance was designed to avoid. As Rails matures, I think we have a
lot to gain by using these techniques.

Thanks for the replies.

I have started using smaller, model centric controllers to handle the
basic CRUD for more simple models. On the more complicated models which
often make use of the simpler models I favor a more use case centric
approach to my controllers.

I’ve also spent some time thinking ahead as to potential number of use
cases and it would be madness to not split functionality into modules,
everything in a flat layout would be terrible to keep track of. This
again works quite well with the above scenario.

Andrew.

We went through similar pains on our app. Eventually it became
obvious with controllers linked to major areas of functionality in
the system. for example, account management, team management, project
management etc.

Another way to go though is to just resign to the fact that
controllers are weak, OO wise, in Rails right now, so simply have one
controller for each page. We started out that way and refactoring
ended up leading us to a better model.


Peter Wright
[email protected]

Personal Blog -> http://peterwright.blogspot.com
Agile Development Blog -> http://exceeding-expectations.blogspot.com

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs