Larger Scale Application Structure

I am developing a larger scale application with rails to manage our
businesses crm, order processing, catalogue, stock control, service jobs
etc.

Define 'large'.

Do you mean large amounts of functionality, large amount of registered
users or high volume of read traffic? (or even write traffic).

If its low-user base, but lots of functionality, you could do it in camping
even.

If the various silos of functionality need to be integrated in some way,
then thats something very different.

I was hoping someone might share experience of a rails app of a larger
size, or specifically how they structured the application to avoid a
confusing mass of controllers and actions.

You start by thinking about your Models and Views first.
If this data is not coming from a database, you need to consider why
you are using Rails even - database-driven is implicit.

If you can focus on what your users do and build your application from that perspective, you will be fine. Each entity (noun) in your system has a model, and that’s where your business rules should be… It’s the user interface that separates the functionality.

You can take that a step further by treating your domain model as RESTful resources, where you typically have a controller for each model. This sort of eliminates complex design in terms of controllers, cos you just know how to add a record to your database.

Sorting things at the UI is a bit trickier, but you will have that in any language. :slight_smile:

Hope that might help! I’m trying to be as general as possible here.

Sorry, I was referring to large amounts of functionality. It is an
internal application with a limited number of users.

Ah *good*. And you answered the other major critical decision (database
driven) with an affirmative too. I was just checking that you weren't using
Rails in a way that will ultimately frustrate you.

I haven't checked camping but will look into it.

It's ActiveRecord at the core. Its even tinier than Rails (a complete
non-trivial MVC web-app in a single sourcefile). It trades off a lot of things
that Rails has, so I wouldn't host my e-commerce site with it, but it's
perfectly valid for small deployments and in your case you could use
it to proof-of-concept Controllers architectures.

I had originally
intended using java with the spring framework & hibernate.

I thought you might have been, hence the questions. hibernate has the
ability to model non-DB data sources, like maybe SOAP services, LDAP
information, etc. I thought that might have been how you were integrating
your CRM & Business processes.

However I

found I was making poor headway using my mix of agile/homebrew methods.
Small changes in direction often needed major refactoring and multiple
updates to code and config.

Hibernate is pretty damn good at integrating with anything, but the price
you pay is code bloat and over-complexity of the common cases.

So far my attempts with rails are looking good. However from experience
I can see things getting harder to maintain as I add more managed
entities and features.

As long as your views and especially your models are done right, I
wouldn't worry too much about it.

>> I was hoping someone might share experience of a rails app of a larger
>> size, or specifically how they structured the application to avoid a
>> confusing mass of controllers and actions.
>
> You start by thinking about your Models and Views first.
> If this data is not coming from a database, you need to consider why
> you are using Rails even - database-driven is implicit.

The entire application is database driven. I think I should spend more
time looking towards user views. Hopefully this may more logically
separate the application for me.

In a green field Rails app, your views are most important, then you
design your models to support them. And glue them together with
controllers.

In your case, if I have interpreted it right, you already have a legacy
database of your CRM system? In which case your Models are limited
to an extent.

You probably have some ideas (or your bosses & users of your old system
do) of your views. Then you have to wire up Views to Models through
your controllers.

In a special case, already mentioned by Brian, you might want to have a 1:1
Controller:Model ratio, and if you expect that you are going to have
a lot of Models it might be worth doing that anyway.

At the end of the day, simplify your controller design by where you expect
the complexity to accumulate. With simple areas you can dedicate one
controller to multiple views and models, but go with a 1:1 C:M ratio
in your feature-popular code.

You are unifying processes that already exist, so you can probably second
guess where those are. Refactoring a 'busy' controller isn't terribly difficult
but it is time you would prefer to spend elsewhere.

@Richard:

Excellent response :slight_smile: