Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Well, actually it's a assignment project and I've already implemented a simple yet functional forum with NodeJS. But now we've been required to use ORM frameworks to refactor part of your code worth refactoring.

As I use Node.JS, there's no such type-safe benefits from ORM I could get. Besides, the code is already functional and I just don't see what good ORM could bring to it...

(Requests are handled pretty swiftly and independently... I don't think I would like to cache tons of Objects from database to request.session...)

My question is, what possible benefits will an ORM bring to a stable NodeJS project?

share|improve this question

1 Answer 1

up vote 1 down vote accepted

ORMs provide a few benefits besides the primary purpose of mapping object data to relational data. A traditional ORM and common 3rd party ORMs may not particularly fit what you are doing, and that is a good starting point for a rationale for explaining why one was not employed, but there are other benefits of ORMs that might want to consider or reconsider.

  • ORMS promotes or enforces the sharing of common interfaces at a distinct layer and system boundary

    When encountering ORM specific types, one should be very close to leaving the realm of application code, and entering persistence code. This should be the case even in the event that you roll up and put in place your own custom ORM over or in preference to a 3rd party's ORM. Ideally, the structure of an application should be that dropping and replacing one ORM and an entire persistence mechanism with a competing or alternative ORM and persistence mechanism without a relative great deal of effort in the form of fundamental change should be relatively painless.

    Some applications go to the trouble of making component replacement a particularly high priority and employ dependency injection to provide the actual ORM provider. In this case, a purely academic setting, DI for the ORM provider is probably not necessary. In fact, most projects would see that is quite beyond unnecessary. For some though, that indirection and flexibility are very valuable as it allows different bits to be plugged in that provide notable situational benefits depending on which benchmarks or features they are chasing. Forum software is one such class of software that might be a good candidate for that kind of flexibility, especially if targeted as a mass-market product.

    Is there a clear distinction between domain behavior and persistency concerns? Does that distinction occur in the same way across the entire or majority of the application?

    Are queries first class citizens, or are they merely presented as formatted strings to a data source? What kind of mechanism is in place to extend or modify a query? Can queries be extended or modified through parameter assignment? How are constraints managed? Can the sorting strategy be easily changed programmatically during run-time? Do not answer those questions here, just consider them as you further evaluate what it might mean to use an ORM or to employ the more prominent if understated features of an ORM.

    Are there any behaviors within the persistence layer that are fundamentally the same and could benefit from further common abstractions?

  • ORMs often provide caching

    Why do we use caching? To keep needed frequently read, but infrequently written data, closer. The only way to know definitively if caching would or would not help is through testing and profiling. However, there are times where it just becomes obvious that some caching might help.

    For instance, promoting a transient variable from a local block scope to a more global scope can be considered a form of caching and can significantly improve performance in the right circumstances. That strategy, not unlike any other strategy has a tradeoff. The tradeoff for promoting a variable's scope is we remove some inherent protections that come with that shorter lifetime and reduce the degree of encapsulation.

    Forum software as a class of software is often a phenomenal candidate for caching. Usually the bulk of forum operations is reading data many more often than writing data, especially considering the many forums have popular topics that are read and reread perhaps many times relative to the number of times new posts that extend the topic are added. The forum software in question may not realize a great benefit as a purely academic project because it may not experience near real world conditions that real world scenarios of many users hammering away at the site would produce.

    Since at this point you are not relying on a third party ORM, your potential caching mechanism and strategy is a bit more flexible. You can use a common provider to cache both post-processed pages and datasets.

There are more benefits to ORMs that aren't mentioned. But as this is academic, I don't want to take all the pleasure out of the research process. Take a closer look what ORMs provide either as a direct, advertised benefit, or as a beneficial consequence or side-effect that often accompanies their use.

share|improve this answer
    
I end up refactoring all those not affected by any triggers/stored routines.... –  phoeagon Jun 3 '13 at 4:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.