Hi David I just had to reply to this.
You are both so right and so wrong at the same time.
The MVC model in abstract i.e. outsode of the rails architecture does NOT as you say prevent other technologies from making use of it. /in fact it actually facilitates this. It’s all about OO development and using the right technological solution in the first place.
A software house I worked for some years ago got a huge order in for an existing client that had purchased a multinational franchise that worked in the same way as their existing business.
This basically meant we either had to write a second version of the massive project they already had with a slightly different interface and maintian 2 completely different projects and in essence provide the same set of business logic twice or we made the existing project which was going through a major re-design phase at the time fit for both solutions.
Neither option was ideal and I was given the rtask of finding the best solution.
The existing project had a Delphi developed front end desktop app working from stored procs on an MSSQL database for use by our clients staff and a ASP web front end for their clients working off the same database with their own stored procs and business logic all over the place.
I had the task of working out the best way forward and in effect invented the MVC model as a solution without actually realising that such model already existed. In fact I only found out about the MVC model when I picked up rails a coupl of months ago.
We needed to recruit more staff for the project and there were no Delphi developers available so we chose to put together a VB team to write com classes that both the Delphi desktop development team could work with and the ASP web development team could work with. We presented a layer of com objects in a core set of views and methids for the front to use and we wrapped up the business logic in a set of hidden (“Friends” to the view objects) business logic components as a second layer of VB COM objects which in turn had their own layer of friends that talked to the database.
This enabled the core VB team to choose whether to use stored procedures or SQL or views or any mix that they chose and also facilitated the ability to switch to any database that the company wanted to use with little or no impact on the desktop or web applications at all.
The problem that we had as an organisation was that the Delphi team fully understoodd OO concepts and loved the fact that they could concntrate on making their screens work the way they wanted them to work and without having to worry about databases an business logic they were able to put together a front end that mapped to the story boards but the web development team had no idea about OO concepts (They just had a very misguided understading of what OO developent is about) and they hated the fact that they “lost control” over the database and the technologies such as ADO that they were used to using and did not like the fact that they had to just worry about getting the web pages put together and how to interact with view layer of com objects.
basically as a totally professional team we got the job done on time and in budget with major satisfaction from the client and the end result was a resounding success and future projects made use of the same model which drastically cut down on development time, code re-working, bugs and unwanted features.
The attitude changed and we saw that we had an advantage over most organisations that chose the traditional route that you have described of putting business logic into stored procedures but the debate to my knowledge still rages over whether to put the logic into stored procs or into the business layer and there are arguments for both but NEITHER option precludes the use of the MVC model as you seem to suggest it’s just that use of stored procs for business logic weakens the MVC model but it does not prevent the model from working.
Basically the MVC model facilitates the use of multiple technologies and the arguents against are usually put forward by people that have little understanding of what it is all about.
Howevewr I would like to see some mention in the book of how Rails can interact with other technologies and how rails could talk to stored procs but I think this whole area is really for a different book.
I picked this book up as I am new to rails and had no understanding of it.
It has taught me a lot and I now know enough to start looking for answers to questions such as this elsewhere.
This book is taking me on a journwy of how to write good rails code and what is good working practice for rails developers and is helping me to understand security risks and how to deal with them and giving me enough info on how to best write an application using rails technology.
If this is what the books intention is then your points made are really for another book and not for this one.
I would love to know a lot more about how rails interacts with other technologies but I think that I would look into this by buying another book or researching on the net as to how this can be done.
Sorry for the epic post but I felt the need to have a rant about a subject that is very close to my heart and please don’t take offence. I hope you can see that I am trying to help you inderstand your misconceptions about MVC.