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.
