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 Edwards
on 2007-04-18 17:19
on 2007-04-18 17:55
On 4/18/07, Andrew Edwards <firstname.lastname@example.org> 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.
on 2007-04-18 18:21
Richard Conroy 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.
on 2007-04-18 18:33
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. :) Hope that might help! I'm trying to be as general as possible here.
on 2007-04-18 20:02
On 4/18/07, Andrew Edwards <email@example.com> 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.
on 2007-04-18 20:17
@Richard: Excellent response :)
on 2007-04-18 20:31
on 2007-04-18 21:00
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 Mango <firstname.lastname@example.org> 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)
on 2007-04-18 21:04
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.
on 2007-04-18 21:08
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.
on 2008-02-19 22:33
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/br... 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