Biomedical Engineering Reference
In-Depth Information
In order to achieve the intended simplicity, RoR expects simple
database tables following a certain naming scheme - if the model is called
Compound the table behind should be Compounds in plural. This is
convention over confi guration. If one already has a big database in place
that does not follow this naming scheme, some of the ease of use and
smartness of RoR disappears. This was true in our case. Tough architecture
discussions therefore started when choosing between changing the
database to fi t RoR and adapting RoR to our existing setup. The database
was the only remaining piece of the old setup, so it was desirable that this
should not enforce the mindset of the old world while using technologies
from the new world, which might have happened in this case.
Building LSP
is
more than just downloading and installing the key
components. They have to be built together in a meaningful way in which
the different parts handle the tasks they are designed to do, and do best,
in the relevant context. But it is not always clear where to make a clean
separation of the layers to achieve the best possible solution. In addition,
programmers may often disagree. RoR follows the Model-View-
Controller [38] paradigm. In the RoR world this, simply explained,
means a model that gets the data from the database, a view that takes
care of the design of the page displayed to the user and a controller that
glues the pieces together. Although it would have been preferable to
follow that layout, it was again realised that our mature database would
force some tough architecture decisions. The database contains many
views as well as Oracle PL/SQL procedures. Should the procedures be
replaced with models and controllers? Would it be better to have a simple
database and then move all sorts of logic into the RoR layer? After some
consideration, the real world answer is that 'it depends'!
Oracle procedures are good for transactions inside the database.
Taking data out of the database, manipulating them in the RoR layer and
putting them back into the database did not seem a very effi cient approach.
On the other hand, it is preferable not to be single-database-vendor
centric. Moving to a simpler table/procedure structure would likely make
it easier to port to other databases if/when that becomes relevant.
Similarly, how to best combine RoR and Extjs was debated. As
mentioned, RoR delivers a way to build interfaces but using Extjs also
meant fi nding a way to elegantly knit the two layers together. A decision
needed to be taken regarding incorporating the Extjs code into the view
part of the RoR MVC setup or keeping it separate. Integrating Extjs into
RoR would tie the two parts very closely together and although that
might have advantages, it would make it more complicated to replace
one of the layers if something better were to appear at a later stage. While
Search WWH ::
Custom Search