> The following blog entry shares much of my idea of ORM in real > applications with large > http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern > > I read this article about a week ago. It is interesting, but I find 2 fundamental problems with it - it assumes premises that are termed as an "either-or"-type scenarios: - You "either" have a relational-data-model, "or" you don't. - You "either" use an abstraction-layer, "or" you don't. These are idealistic-premises that do not map to reality. In reality, you have a hybrid-data-model, with some areas that are more "relational" than others - all co-existing within a single database. In reality, you almost always end-up dealing with a framework using "multiple" abstraction layers, at different areas of your application, depending on how well a given use-case maps to higher-layers of abstractions that the framework provides.
Another MAJOR issue, with basically every critique I have read about ORMs, is that they almost EXCLUSIVELY target the Active-Record pattern. The entire first half of the SQLA lecture I posted here, is talking explicitly about this, and goes into great detail in describing the problems inherited in the Active-Record pattern. Another SQLA lecture I put here, is discussion exactly about the reality of abstraction-layer-usages that I have described, in terms of a hybrid-approach. It also shows how a layered-approach has benefits that surpass the shortcomings of having to learn multiple layers (a problem that the article touches upon). Contrary to ANY ORM out there, SQLA provides BOTH a relational-layer AS-WELL as an ORM-layer on-top, both of which use the same SQL-Expression syntax, using python-objects: - No need for a 3'rd language like Java-Hibernate's HQL. - No need for manual SQL witing. - SQLA-DAL (SQL-Expression layer) is EXPLICITLY uses throughout the build-up of ORM classes by the developer, and is NOT assumed to be treated as a "hidden" layer. - SQLA-ORM is NOT using the Active-Record pattern (so basically ALL criticisms you generally read about ORMs, do NOT apply...) - SQLA-ORM layer is OPTIONAL(!), and even if you DON'T use it, you STILL DON'T have to write SQL(!) You use SQL-Expressions, which is ALMOST IDENTICAL to web2py's DAL (!) Basically, almost all of that article is completely irrelevant to SQLA, and hence to the model that I am proposing here. As to OOP, again, it is almost exclusively-criticized in respect of the Active-Record pattern (which again, is irrelevant here...) SQLA's ORM, and hence what I am proposing, goes in line with the article's proposals near the end, which is: "For relational-models, go with a more direct-SQL layer for using the data, and build business-logic layers on-top." Most of what SQLA's ORM is providing, is "automation"-tools, for helping the build-up of business-logic classes "on-top" of a pythonic-SQL-abstraction-layer. My 4 points where I think that DAL can be (and so has to be ;-) ) improved: > > 1. lazy rows being backed by a sql cursor when requested by the user; > 2. since point 1. is not always the solution, row object instance creation > must be way faster; > 3. a simple way to support db indexes even at a basic level; > 4. sql view/readonly tables support (this could be related to cacheable > tables). > I would add: 5. A configurable mechanism based on the "Unit-Of-Work" pattern. -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
