I am not as learned in these things but it seems to me that a DAL is a small black box, whilst an ORM is a larger black box.
If I look inside the DAL 'black box', I can just about figure out what's going on. If I look inside an ORM black box, it is already too complex (for me). If we add the two black boxes together, it would only be maintainable by someone of Massimo's skill level (and even he thought it was too complex for his needs, hence the DAL!). I cannot imagine that anyone would commit themselves to such a project. Perhaps we should try to list some of the benefits? Otherwise we shall remain theorists in pursuit of a hypothetical abstraction - which never looks good on a CV. On Wednesday, May 1, 2013 11:02:38 PM UTC+1, Arnon Marcus wrote: > > I am not re-defining terms - I understand them correctly. > An ORM is a "Mapping" between "Objects", and "Relations". > > Here are the parts of the wikipedia pages, that are actually-relevant* * to > this discussion (important parts in bold-text): > > *ORM:* > "...Data management <http://en.wikipedia.org/wiki/Data_management> tasks > in object-oriented (OO) programming are typically implemented by > manipulating *objects<http://en.wikipedia.org/wiki/Object_(computer_science)> > that > are almost always non-scalar<http://en.wikipedia.org/wiki/Scalar_(computing)> > ** values.* For example, consider an address book entry that represents *a > single person along with zero or more phone numbers and zero or more > addresses*. This could be modeled in an object-oriented implementation by > a "Person object <http://en.wikipedia.org/wiki/Object_(computer_science)>" > with attributes/fields<http://en.wikipedia.org/wiki/Attribute_(computing)> to > hold each data item that the entry comprises: the person's name, *a list > of phone numbers, and a list of addresses.* The list of phone numbers > would itself *contain "PhoneNumber objects" *and so on. The address book > entry is treated as a single object by the programming language (it can be > referenced by a single variable containing a pointer to the object, for > instance). *Various methods can be associated with the object, such as a > method to return the preferred phone number, the home address*, and so > on." > > The first thing to notice here, is that an ORM object-attribute can > contain NON-SCALAR values - meaning, a link to a list of other objects. > There is no feature in web2py that generates such an object. > > The second thing to notice here, is that the attributes of an ORM object > usually contain child-objects (plural) that represent fields from a > different table than the parent-object. Again, there is no feature in > web2py that can generate such an object. A JOIN operation may return row > objects, each of which may contain sub-attributes that hold A SINGLE > field-value > from a foreign-table, but it is a *scalar-value* - NOT another * > domain-entity-object* (with it's own attributes, etc.), NOR a SEQUENCE of > *domain-entity objects* > > Here are some diagrams that presents it really well: > > <http://www.jfwk.com/images/p2.gif> > > <http://software-carpentry.org/3_0/summary/orm.png> > > > <http://www.visual-paradigm.com/VPGallery/img/orm/ERDiagramAndClassDiagramSynchronization/ER-Diagram-and-Class-Diagram-Synchronization-Sample.png> > > The crucial thing to notice here is that an ORM object-attribute can > contain NON-SCALAR values - meaning, a link to a list of other objects, > which themselves may contain links to other objects/sequences-of-objects, > etc. > > > As for DAL, here is the part of the wilipedia page, that is relevant to > this discussion: > > "...*Popular use for database abstraction layers* are among object-oriented > programming <http://en.wikipedia.org/wiki/Object-oriented_programming> > languages, > which are similar to API level abstraction layers. In an object oriented > language like C++ or Java, *a database can be represented through an ** > object* <http://en.wikipedia.org/wiki/Object_(computer_science)>*, whose > methods and members* (or the equivalent thereof in other programming > languages)* represent various functionalities of the database.* They also > share the same advantages and disadvantages as API level interfaces." > > As you can see, even wikipedia says that there is more to a DAL than just > the SQL translation. > > Here is another usage of the same "Three Letter Acronym" (DAL), that > represents how an ORM is layered on-top of a DAL: > > > <http://vaadin.com/download/book-of-vaadin/vaadin-7/html/img/jpacontainer/jpa-mapping-graphic-lo.png> > > > <http://vaadin.com/download/book-of-vaadin/vaadin-7/html/img/jpacontainer/three-layer-architecture-lo.png> > Obviously, THIS dal is not an abstraction-layer, but an access-layer, but > it could very-well be substituted by an abstraction-layer that does the > same thing. > > Granted, this is a different form of an ORM, directly mapping > class-attributes to table-fields, but in principal it is the same - an ORM > is a layer on-top a DAL, that uses a DAL. > > > > -- --- 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.
