AndyV, first of all, thanks for your enlightning reply.
Back to the topic, let me reply to your post by splitting it in smaller
I think you'll need to be more specific about what you mean by the
"API problem" before you can get really helpful comments on that.
Ruby does not have the same type of interfaces that you've come to
rely on C# and similar languages. It's much more reliant on duck-
typing and, used effectively, you can achieve a similar result.
Specifically, you don't worry about whether or not a class implements
a specific interface; from a duck-typing/Ruby perspective you _really_
want to know if it performs some method. And if that's your
objective, you just ask it:
You can then move on gracefully if your object does not respond to the
method in question or raise an exception if you prefer exception
handling for that type of thing.
Yes, I could do that. It just feels strange that there's no real
contract enforced by design, only at runtime by the "host / invoker". In
practice it boils down to a matter of principles and vicious programming
styles, where you apply the same design patterns over and over,
throughout the countless projects.
You will also want to look into using 'modules'. Modules fall
somewhere between interfaces and abstract classes on the C# scale.
They allow you to craft a specific interface, interact with private
state of the class, but do so at a completely abstract level. For
example, in one application I've built I have things like addresses
and phone numbers and the like that are valid for a particular date
range. I needed to allow the user to say 'replace the home address/
phone with X value starting on Y date'. To handle that I wrote a
module that dealt only with the activation and deactivation dates and
provided a simple api for asking whether the instance that I found was
the currently active on, or to find the one that was active on a
specific date. It also enforced the rules about preventing two
objects from being active at the same time. What was nice was that
the module gave me the api (interface) but I could program it with
real instance/state information (abstract class) but without caring
what class I was dealing with or imposing a requirement that the
classes themselves implement the method (interface).
The MVC framework may not be a huge help to you if you've been a
particularly disciplined OO developer. Unfortunately I've done enough
project where I was always perfectly disciplined and everyone else
messed things up. MVC is a good guide for everyone because it
_helps_ enforce proper separation. It's the same type of n-tiered
solution that .net developers always want until the drag-and-droppers
Not a huge help at all... I'm a MVC beginner. Therefore, I can only hope
that what I now consider to be a feature that complicates what was
simple will become a plus over time. Hard to forsee such future, just
As for the URL issue, there are several ways to get to the kinds of
urls that you want. In fact, one of the reasons that many people like
rails is for the same kind of clean urls that you've apparently been
using. There are a few things that will be helpful for you to achieve
those urls. First, you can use namespacing. This is similar to what
you'd do in .net in that it allows you to segment the application and
group similar concerns within the overall solution. What's as nice
(or better) is that the organizational principle gets reflected in the
url as well. That is, all of your admin or management views would be
grouped together in the project AND the url would include /admin or /
management as you've described.
Sounds like a very interesting and promissing thing. Will have to dig
The default routing, particularly nested routing, would help you go
even further. By convention, rails generates routes that follow a
Which is to say all your customers could be retrieved by hitting /
customers, but a specific customer would be found by hitting /
customers/1234 (where, by convention, 1234 is the id of the
customer). One of the nice things that you can do, though, is to
override a method specifically used by the routing so that your url
instead looks like
where pragmatic_programmers is the name of the customer, downcased and
with underscores added. Your customers might like that even more
since they could bookmark 'frequent flyers'.
Nested routes are similar. The 'nesting' comes in the fact that you'd
get /parent_collection/[parent_token]/child_collection[token]. The
format can be really handy when you're adding a new item to a child
collection because the identifier is passed along to the controller
that handles the children.
It's also worth noting that you can completely bypass the RESTful
routing if you want. The routes.rb file permits several ways to add a
url to the route map so you can continue to use the same kinds of urls
that you are using today. In short you give the route a name,
describe it's pattern (perhaps with a string), and then tell it what
controller and action (method) should respond. The routing system
even permits regex matching, making it easy to provide, for example,
dated blog entries that conform to something like /posts/2008/may.
Yes, it's somewhat familiar with the ASP.net 3.5 extensions MVC
As a reformed C# guy myself I can say that I never look back and wish
I had the 'opportunity' to select just the right collection of objects
and configurations from among the 25K+ that MS has to offer. In fact,
I'm thankful every day that I hooked up my friend to do contract work
on a legacy project so I can stay .net free for yet another day!
When I saw Rails, and started reading more about it, I've considering
dropping .net all together. Well, for the web at least. Only the test of
time will tell how fast I apply the same, or adjusted patterns, to rails
and if that makes me save money or waste money.
Feel free to contact me off line if you want to talk any more
Could you send me and e-mail and / or MSN to ahkaru [at] gmail [dot] com
? Would be interesting to discuss a couple of points with you.
Best regards and thanks again.