Rails - Apr 2009 - Architectual question: Engine with all common models

I am maintaining a large Rails application, that consists of several
"interfaces":

1) The web interface (figures)
2) Import of data from external providers
3) Export of data to a large range of customers

It seems to me quite bloated to have all the code from 2) and 3) inside
the web-application, since they functionally have nothing in common. The
only reason for them being there, is that they also need the business
rules implemented in the models.

Enter Rails 2.3 and Engines...

I am thinking about restructuring the application the following way, and
my question regards whether this is a sound idea.

i) Make a Rails engine, consisting only of all models, that are shared
by two or more of the above "interfaces"

ii) Split my current application into 3 seperate applications - each
only containing what is nessecary for its own uses:

1a) Web interface should only keep: Controllers, Views,
Mailer-"models"
(and other dependent files in e.g. lib)
2a) Import of data should only keep code needed for the import
3) Same as 2a)

All three of them should then add the "model-engine" in their vendor
folder.

I am not sure if Engines were meant to be used like this - but somehow
it fits in my mind. Any thoughts on this?

- Carsten
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I allow myself to bump this question just once, since I believe, that it 
is quite relevant at the moment, considering the release of Rails 2.3

- Carsten
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Carsten Gehling wrote:
> I am maintaining a large Rails application, that consists of several
> "interfaces":
> 
> 1) The web interface (figures)
> 2) Import of data from external providers
> 3) Export of data to a large range of customers
> 
> It seems to me quite bloated to have all the code from 2) and 3) inside
> the web-application, since they functionally have nothing in common. The
> only reason for them being there, is that they also need the business
> rules implemented in the models.
[...]
> ii) Split my current application into 3 seperate applications - each
> only containing what is nessecary for its own uses:
[...]

I am not 100% sure that I''m correctly understanding the current 
structure of your app, but if I am, my advice is this: you have one 
application, accessible through multiple channels.  Keep it that way -- 
since it''s one application, it probably shouldn''t be broken
down any
further from the user''s point of view.  Just keep everything
modularized
well enough that the interfaces don''t have much coupling to the models.

(Of course, Phlip is liable to say something totally different, and if 
he does, you should definitely listen to him, not me.)

Best,
--
Marnen Laibow-Koser
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
http://www.marnen.org
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

One issue with splitting the application into 3 will be consistency of
deployment. If the models in the engine change you need to at a
minimum run all the tests in all 3 systems, and possibly make updates,
then find the time to deploy all 3. I know these situations are
solvable, but I don''t think it''s worth introducing them if you
strive
to keep all your interfaces (web, import, export) well separated. You
could add something like app/importers and app/exporters and treat
them like "controllers" for the alternate interfaces. Also, the use of
modules and namespaces can be useful for situations likes this.

On Apr 12, 6:45 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> Carsten Gehling wrote:
> > I am maintaining a large Rails application, that consists of several
> > "interfaces":
>
> > 1) The web interface (figures)
> > 2) Import of data from external providers
> > 3) Export of data to a large range of customers
>
> > It seems to me quite bloated to have all the code from 2) and 3)
inside
> > the web-application, since they functionally have nothing in common.
The
> > only reason for them being there, is that they also need the business
> > rules implemented in the models.
> [...]
> > ii) Split my current application into 3 seperate applications - each
> > only containing what is nessecary for its own uses:
>
> [...]
>
> I am not 100% sure that I''m correctly understanding the current
> structure of your app, but if I am, my advice is this: you have one
> application, accessible through multiple channels.  Keep it that way --
> since it''s one application, it probably shouldn''t be
broken down any
> further from the user''s point of view.  Just keep everything
modularized
> well enough that the interfaces don''t have much coupling to the
models.
>
> (Of course, Phlip is liable to say something totally different, and if
> he does, you should definitely listen to him, not me.)
>
> Best,
> --
> Marnen Laibow-Koser
> mar...-sbuyVjPbboAzsqOy+PStLQ@public.gmane.org://www.marnen.org
> --
> Posted viahttp://www.ruby-forum.com/.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Marnen:
> you have one application, accessible through multiple channels.
> Keep it that way -- since it''s one application
Andrew:
> One issue with splitting the application into 3 will be
> consistency of deployment
> You could add something like app/importers and app/exporters
> and treat them like "controllers" for the alternate interfaces.
These are good points, both of you, and they made me think some more 
about the layout of my application.

What really bothers me is that, right now, all import code is started by 
executing "script/runner Janitor.perform_daily_tasks", where Janitor
is
a class defined in the model folder. This means, that the "Janitor
code"
is automatically loaded by Rails, adding code to each mongrel that has 
nothing to do with the web interface.

I think I will try to convince my colleague, that do the app/importers & 
app/exporters approach. It seems the right way.

Thanks a bunch both of you.

- Carsten
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---