Larger Scale Application Structure

Rails
1

Hi,

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

Logically the application has distinct modules or sections of
functionality. As you can imagine there are also many cross cutting
dependencies between the areas of functionality.

Initially I have considered breaking it into ruby modules, primarily
grouping application controllers into areas of functionality.

As a guide, in terms of number features and screens I would say it will
easily exceed any of the 37signals products I use. I could equate it to
rolling basecamp, highrise and campfire into one application.

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.

Regards,

Andrew E.

2

On 4/18/07, Andrew E. [email protected] wrote:

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.

3

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.

4

Richard C. wrote:

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.

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

I haven’t checked camping but will look into it. I had originally
intended using java with the spring framework & hibernate. 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.

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.

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.

Thanks,

Andrew.

5

On 4/18/07, Andrew E. [email protected] wrote:

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.

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.

6

I have a JEE enterprise resource planning system that my group at my
job has been working on for a while now. We only have a few people, so
it is very time consuming. We are currently exploring the idea of re-
writing our system in Rails. We decided to take a RESTful approach.

In organizing our application we looked at each module. For example,
Customers, Quotes, Sales Orders. We consider these ‘documents’.
Documents are sort of like packages of related models. For example,
sales_orders have many sales_order_line_items and
sales_order_line_items have many
sales_order_line_item_delivery_schedules. We then broke our models
down into namespaces that relate to their related documents. For
example, we have models like: Customer, Customer::Bill,
Customer::Ship, Customer::ship::Account. We use nested resources
(RESTful specific) to refer to a things inside the namespace. For
example, you can’t access a customer billing address without
references the customer like: /customers/:customer_id/bills/:id.

We also have a lot things we call ‘lookup objects’. For example,
customer_ship_accounts belong_to shipping_method. There are shipping
methods like UPS, FedEx, etc. But shipping method is not only used
with ship_accounts it is also used directly in other modules. In the
case of lookups the models are defined like: Lookup::ShippingMethod,
but their table names are like: shipping_methods.

Our main goal was to make things as simple as possible compared to our
old application. We wanted everything organized and we wanted to write
as little code as possible. We didn’t want to depend on javascript in
our interface. We thought it would be nice if we had an API out of the
box.

All in all, it is working out quite nicely. The scaffold_resource
generator has a few bugs when it comes to models with namespaces so
deep, but we are working through them and eventually we plan to write
a generator based on scaffold_resource that helps us more.

On Apr 18, 11:19 am, Andrew E. [email protected]

7

How do you deal with namespaced models and fixtures (for unit tests).
I tried playing around with putting my models in namespaces, but it
seems a bit buggy in that regard.

-carl

On 4/18/07, Thomas M. [email protected] wrote:

example, you can’t access a customer billing address without
references the customer like: /customers/:customer_id/bills/:id.

–
EPA Rating: 3000 Lines of Code / Gallon (of coffee)

8

@Richard:

Excellent response :slight_smile:

9

To be honest, we haven’t tackled that yet. We are still proving that
we can efficiently develop a large scale application using Rails
compared to our previous framework.

10

Everyone, some great advice. Thanks very much.

I’m always keen to read people’s opinion on high level application
architecture and planning. I don’t often find it a topic for
consideration in most rails text’s or manuals. I suppose many of the
best practices are naturally abstract to some degree and need to be
interpreted for each language or framework. As such these are available
but not necessarily under the guise of a ruby or rails book/webpage.

Thomas, it sounds as if your project is quite similar. It is reassuring
to hear of a similar project making good progress. Thanks for the tips.

Andrew.

11

Hi,

I have just come across your post on this subject. It relates to
something I am trying to do and I have just raised a new post.

http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/e64863c972e6796e

I want to separate out my Admin functions into a namespace. I have
got the routes and the model etc working, but I cannot get my head
around how to do testing. Also, the models are going to need to be
shared. eg. ideally, the user model should be managed under admin,
but needs to be accessible for user login.

I just wondered if you had any success with the approach you were
taking and whether you may have any pointers you may be able to share.

I am beginning to think I may need to split admin into a separate
application and therefore have two distinct Model interfaces, one for
admin and one for user level.

Thanks
Tonypm