small medium large xlarge

25 Jun 2008, 20:35
David Wilbur (50 posts)

this section basically paints the worst of database centric programming and imo, its presentation rather unfair to the state of things. at one time this might have been the prevailing way to code a database application, however i can’t remember the last time i did it like the example as presented.

in most new systems that i have worked on the model is for the most part accessed though stored procedures. granted, that means that it probably under the covers is doing something similar as to what is presented. this approach however, means that for all languages and solutions that interact with that model, they all have to conform to the rules of the model and those rules are the business logic.

to me one of the detractions of the rails model (as in mvc model) is that doing things this way ignores the rest of the world that might have to interact with the model. forcing them to have to redundantly implement code that is in the rails model.

how rails views database models that are not rails centric (ie: pre exsisting databases to a rails project) is rather difficult and annoying to deal with.

lastly, ActiveRecord, from my perspective, deals with the database from the standpoint of a dumb data store and if it did a better job of allowing you to move most of the model into the database server, via say mapping model methods to stored procedures then greater efficiencies might be achieved. also, it might allow rails to do a better job of playing well with others.

to be fair to the reader, so that they are able to better assess where rails is a good solution, and other tools/methodologies are better… things along this line need to be mentioned. the way that it is presented in my mind does a disservice to the reader, because it presents it only in a good light ignoring detractions, and setting up the reader to failure via unrealistic expectations.

26 Jun 2008, 01:49
James West (104 posts)

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.


26 Jun 2008, 03:06
David Wilbur (50 posts)


i am not saying that mvc is bad and i think i understand mvc rather well. i am saying that, the way rails accomplishes it it doesn’t play well in a multi language, multi product situation where there is/might be already an existing setup. that the section of the book is written in such a way that it glosses over issues that one might encounter, and … goes to an extreme to make a point and thus misleads.

i am just suggesting that the section mentioned is not helping people by going to such an extreme contrast and that it might help to forewarn people about some of the places that rails might not be the best solution. this being a book that people are pointed to as to start with, is to me exactly the place where it should talk about the pluses and minuses of the product. if i implied that i wanted more then that, in the book, that is not what i intended.


26 Jun 2008, 04:18
James West (104 posts)

Hi David, No problem.

I don’t have enough knowledge of rails to fully understand its limitations yet and maybe this is a failing of this chapter.

I suppose the subject of when and which technologies to use in the real world is more of an epic encyclopedia than a book, never mind a chapter. I can see that it would be difficult to integrate rails with other technologies but I guess I just don’t understand yet which technologies I would have a need to integrate with as Rails seems to me, at the moment with my very limited knowledge of it to be able to provide all the facilities I would need. Having said that I am just about to emnbark on my first major web app and it is a pretty large undertaking and I am sure I am about to find out for myself just what it’s limitations really are :-)

So I guess a forewarning would be very useful especially as I guess I am the target audience and I still don’t know just what these limitations are.

Oh lordy with 1 major app about to get underway with another 3 in the pipeline and currently in the planning stages just what am I letting mysel in for by going down the rails route wthout fully understanding this ;-)


You must be logged in to comment