RoR: Managing long actions through better workflow

[mastaBlasta]

-Also posted this on Ruby Forum
I'm working with Ruby on Rails, but any MVC framework i'm sure encounters this issue.

In our application we have a number controller actions that have gotten
very long and difficult to maintain. Usually #create and #update. A huge
reason for this is that the objects handled by the controllers have a
bucketload of associations that must be handled according to a complex
set of business requirements.

In short things have gotten complicated and I'm looking for a way to
break up the code in more manageable chunks. I know this is an endeavor
as old as programming itself, but I hope people can share some of their
experiences.

The code i'm dealing with in particular has a lot of error checking. If
this & this then fail. If this but not that then fail, and so forth. Of
course every conditional has various error messages that must be sent
back to client and else clauses and blah blah.

It would be interesting to have some kind of callback system, that
monitors different stages of the #create workflow for example, and when
an error is encountered it bombs out, finds the correct message to
display and returns to view.

 

[krogen]

I haven't encountered any such issues, but I am a novice programmer and haven't worked on very complex projects yet.

I am also not exactly sure how Active Record works in Rails, but from my experience with DataMapper (I often work with Sinatra) I usually like to write a lot of code in models themselves, if it makes sense to do so. Perhaps it doesn't apply very much to what you're doing (handling complex situations), but it could be used to transfer chunks of the code to the models, which would make your handlers cleaner.

 

[PTNL]

What kinds of processing times are you getting with the creates/updates: several seconds, minutes, etc.? If there's a database somewhere, what metrics have you gathered on it? Have you identified a list of the worst performance offenders? If so, what has a profiling application revealed?

What performance metrics have you gathered on the front-facing server, the number of calls going between multiple servers when processing transactions, and the connectivity throughput? Are you writing trace logging messages as the server-side requests are processed? Is this issue more susceptible under load?

If your Controller files are becoming bloated, then have you considered abstracting out into further classes and/or subclasses? Are you using threading (with callback functions) on this, or are you operating on the same thread? What happens when you fire off a bunch of rapid-fire calls to the business logic methods? What about asynchronously? Is localizing the return messages a need/requirement?


Hopefully the above questions will lead to discovery and solution.

 

[mastaBlasta]

What kinds of processing times are you getting with the creates/updates: several seconds, minutes, etc.? If there's a database somewhere, what metrics have you gathered on it? Have you identified a list of the worst performance offenders? If so, what has a profiling application revealed?

What performance metrics have you gathered on the front-facing server, the number of calls going between multiple servers when processing transactions, and the connectivity throughput? Are you writing trace logging messages as the server-side requests are processed? Is this issue more susceptible under load?

If your Controller files are becoming bloated, then have you considered abstracting out into further classes and/or subclasses? Are you using threading (with callback functions) on this, or are you operating on the same thread? What happens when you fire off a bunch of rapid-fire calls to the business logic methods? What about asynchronously? Is localizing the return messages a need/requirement?

Hopefully the above questions will lead to discovery and solution.

Performance wise everything runs very well. It is only one thread and i don't see that changing in the near future. Breaking things up into other methods would be the way to go but that's just the issue, that these are not overly complex interactions. Most steps are things like "if this association is set to this, then this association must also be set to this, otherwise throw error". It's in essence a very, very long "validation", but i don't want to use that word because it usually involves multiple models so it's not the traditional model validation.

So breaking it up into multiple methods would yield a large collection of stub methods that are meaningless on themselves, unless used in a specific order by a specific call.

 

[PTNL]

Performance wise everything runs very well. It is only one thread and i don't see that changing in the near future. Breaking things up into other methods would be the way to go but that's just the issue, that these are not overly complex interactions. Most steps are things like "if this association is set to this, then this association must also be set to this, otherwise throw error". It's in essence a very, very long "validation", but i don't want to use that word because it usually involves multiple models so it's not the traditional model validation.

So breaking it up into multiple methods would yield a large collection of stub methods that are meaningless on themselves, unless used in a specific order by a specific call.

Where and how you split things up is not an easy answer, and you're the only person on this thread that can make such a judgement call. After reading your second post, it sounds like much of the driving force is from a maintenance/maintainability perspective. Then again, perhaps you simply need to acknowledge that there's going to be sections of that application that are the "pitbull in the corner" -- code blocks that you'd rather not mess with right now.

Then again... I see that not only are you facing refactoring challenges, but I'm speculating that there is a need for another set of views/controllers to serve up the model in a different way. Then again, maybe I'm reading too much into what you're describing. But the way things are worded right now, this thread feels like a "tip of the iceberg" scenario.