In my opinion most mature/complex client/server or n-tier applications
using SQL Server, Oracle, or MySQL, use stored procedures.
Without support (except by use of the execute method) for Stored
Procedures, Ruby on Rails or MonoRail is a Show Stopper. We are unable
to effectively use Ruby On Rails as all access to the db is using Stored
Procedures.
This does not mean that we are unable to use ORM. In fact, if we were to
be able to consider a Store Procedure results set as a View, we can
easily analyze the view (or DataSet) returned as a first step in
creating/updating the objects and their classes.
As to ActiveRecord, and ActiveRecord is not a proper representation of a
Busines Object. I think the patten is simplistic and although useful, it
is not sufficient. In my opinion we should have Busines Object
Collections and Business Objects. To create a Business Object Collection
we sould need to interate through the ActiveRecords.
I’d appreciate any comments, pleas to
[email protected]
Thanks
Alex Y. wrote:
intrader wrote:
In my opinion most mature/complex client/server or n-tier applications
using SQL Server, Oracle, or MySQL, use stored procedures.
That’s one way to skin the cat, certainly. In my opinion most complex
n-tier applications should be broken into tiny pieces (with great
prejudice, ideally) that don’t need them. Then again, my opinion
doesn’t count for much. I’m not a bank. Neither are most of Rails’
users.
Yes, many ways to skin the cat - in our case, application programmers
are restricted from directly accessing the db. Everything is thru Stored
Procedures.
Without support (except by use of the execute method) for Stored
Procedures, Ruby on Rails or MonoRail is a Show Stopper. We are unable
to effectively use Ruby On Rails as all access to the db is using Stored
Procedures.
Then I guess you’re not going to be using Rails 
Truth be told, I
can’t see it being that hard to write an AR equivalent to (as you point
out) use a returned dataset as the basis for an access object.
I am impressed with Rails clean MVC vs. the somwhat muddled .NET way.
As to ActiveRecord, and ActiveRecord is not a proper representation of a
Busines Object. I think the patten is simplistic and although useful, it
is not sufficient.
What do you think is missing?
In my opinion we should have Busines Object
Collections and Business Objects. To create a Business Object Collection
we sould need to interate through the ActiveRecords.
Not sure I follow here. What would you be able to do with a business
object collection that you couldn’t do with a class method in AR?
What’s missing? And what’s stopping you from implementing an
ActiveRecordCollection that does it, then showing us why it’s better?
I sm missing something, as I am not a Rails programmer (yet). What I see
is that your model classes inherit from ActiveRecord. And yes I don’t
see any problems in implementing an ActiveRecordCollection. I just
don’t know Rails.
–
Alex
On 1/9/06, Alex Y. [email protected] wrote:
And yes I don’t
Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
I encourage you to investigate overriding the basic CRUD operations
within
AR to utilize direct SQL calls in their stead. You will run into an
organizational issue in that introducing SP’s into the call stack
introduces
an additional indirection in naming the operations. What I mean is…
SQL
is standard… .there is only one way to say “SELECT FROM”. OTOH, your
SP
could be named ANYTHING (“sp_something_get”, “sp_something_read”,
“whatever_you_like_to_call_it”). And in my experience, you are very
lucky
if you have a DB Admin team that has absolutely used the same naming
convention across the several hundred procedures in your database.
Rails can do this. You can alter the system to perform this trick. I
would be very interested in your results.
Good Luck.
–