On Jun 4, 2010, at 2:10 PM, Marnen Laibow-Koser wrote:
Raf Jaf wrote:
[...]
The point of avoiding ActiveRecord is because our data sources are
disparate, meaning that they include databases, mainframes, and, in
some
cases, sources that expose only a message-based interfaces (JMS,
etc).
ActiveRecord and ActiveResource will have no problem with this.
Oh? ActiveResource can have a JMS queue as an input?
Furthermore, data from these sources needs to be mapped and processed
through rules before being populated in model objects and presented
to
the client. Our Java data services layer handles all of this, so it's
just a matter of integration Rails/Ruby with that interface.
Don't bother. ActiveRecord can handle that too.
We intend
to use Rails for our presentation tier only, not as a end-to-end
solution.
Then you are making a very poor decision. Stop now. Rails is an
end-to-end solution. Either use it as one or go with something like
Sinatra or Ramaze that is better suited to your use case.
The Java framework already exists, and we want to reuse what we have
available.
Does that make sense now?
No, for the reasons above.
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Reusing code that exists and WORKS is typically a very sensible idea.
Assuming that the others system from which the data comes will remain,
creating ruby models that wrap the existing data source is fine. (And
avoids duplication!) With the separation of modules in Rails 3, you
should even make those models behave sufficiently like an ActiveRecord-
based model with relative ease.
-Rob
Rob Biedenharn
http://agileconsultingllc.com
[email protected]
http://gaslightsoftware.com
[email protected]
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
