>> Is it true that XPO does not supprt lazy loading of objects? This is incorrect. XPO does support lazy loading. Lazy loading is accomplished by using an XPO specific class as the underlying private member. You then can strictly type the value using
a Property Get/Set. From the XPO help system:
public class Customer: XPObject {
...
private XPDelayedProperty document = new XPDelayedProperty();
public Byte[] Attachment {
get { return (Byte[])document.Value; }
set { document.Value = value; }
}
}
I realize most of this thread discusses the object to relational mapping challenge but what everyone neglects to mention is that XML causes the same kind of impedance mismatches. Check out the PDF document titled Unifying Tables, Objects and Documents at Microsoft
research http://research.microsoft.com/Comega/ Hopefully some of these ideas see the light of day in the not to distant future.
Could Xen look any more broken? What elevates XML to the status of a first-class construct anyways? Why not RTF? Why should XML or SQL get higher level treatment than say, Binary formatting? What does Xen actually accomplish anyways? Strongly Typed Queries?
Well, it also moves us away from a Domain Model, and towards a Data Model. I think that's the wrong direction personally. Anonymous Delegates seem to accomplish the same thing as anonymous methods as far as I can tell btw.
The research into Omega is simply recognizing and embracing the prevalence and relevance of both the relational model and XML dialects. As far as what this accomplishes I thought that would be obvious. Anything that can obviate the need for mapping between
these diametrically opposed layers is a good thing in my estimation. Good provided things like performance, language expressiveness, ease of use, flexibility and so on are not lost. Tightly coupled binary formats such as DCOM and CORBA have come and gone for
a reason. Sure these formats provide good performance but at what price. Kevin
Moot Isn't the Domain model simply composed of many data models? Data models are therefore complementary to the domain model and not contradictory to it. Perhaps I'm not understanding the point you are trying to make. At some point the data has to be represented
in some malleable form that people can work with and exchange. Since XML is standards based, transport, language, OS and development platform agnostic I think it's an excellent choice. Sure XML has it's warts like anything else but I think the positives far
out way the negatives. Kevin
It's two views of the same thing. The problem OOP tries to solve (in my humble opinion) isn't "where do you put data", or even "how do you manipulate data", but where do you put behaviour, and how do you encapsulate it? In that regard, Data models such as Xen
allows break the domain. You talk of fads, but what about networks? Is TCP/IP a fad? And yet we don't compromise our domain for the network (by altering the language to resemble network constructs). We enhance it (by adding tools that eventually made their
way into core API's) to support the network. Put it this way: If you could have high performance transparent O/R mapping and XML serialization, then would Xen even be relevant at all? (I'm actually not arguing against XML at all, just the suggestion it be
made part of the language.) Perhaps I'm too stupid to understand it, but to me, Xen looks like a step backwards, and the potential for abuse anonymous structs and methods allow look like big flashing GOTO statements. But I could be wrong. I'm after all, relatively
new to all this myself. :)
You forgot to mention the attributes of the object that store the information about the object. Of course the attributes represent the data in its transient form before the data is persisted again (i.e. to database). You can't have behavior without the data
and data is practically useless if you can't act on it. I now understand what you mean by breaking the domain model. XML and OOP can certainly be characterized as different domains but they are attacking very different problems. It really is a conundrum when
you think about it. The OOP approach to data exchange as I mentioned is more tightly coupled and therefore more fragile in distributed scenarios. COM, CORBA, Java and .NET OOP all fall into the binary quagmire and by their very nature are incompatible. Even
if a universal OOP/binary compatible platform existed you would still have to deal with the inherent weakness of such a platform. I.e. tight coupling and backward compatibility issues as platform evolved. XML on the other hand is infinitely malleable and platform
independent making it a good choice for data exchange. Perhaps a more XML centric programming model, at expense of OOP, would be appropriate but then one would be giving up encapsulation which is practically a necessity in complex systems development. The
Xen developers may be making a capitulation but I would characterize it as a practical compromise. Many issues to consider indeed! Kevin
rsmoke21
Contributor
3931 Points
792 Posts
Re: Your favorite O/R Mapper?
Nov 02, 2004 02:44 AM|LINK
public class Customer: XPObject { ... private XPDelayedProperty document = new XPDelayedProperty(); public Byte[] Attachment { get { return (Byte[])document.Value; } set { document.Value = value; } } }cgastin
Participant
1045 Points
209 Posts
Re: Your favorite O/R Mapper?
Nov 02, 2004 04:39 AM|LINK
SCJP 1.4, SCWCD J2EE
http://www.chrisgastin.com/blog
BLOG: The Trek of a Java Developer Learning .NET
kevin.weir
Participant
850 Points
170 Posts
Re: Your favorite O/R Mapper?
Dec 12, 2004 12:41 AM|LINK
ssmoot
Participant
1760 Points
352 Posts
Re: Your favorite O/R Mapper?
Dec 13, 2004 12:19 AM|LINK
kevin.weir
Participant
850 Points
170 Posts
Re: Your favorite O/R Mapper?
Dec 13, 2004 11:37 PM|LINK
kevin.weir
Participant
850 Points
170 Posts
Re: Your favorite O/R Mapper?
Dec 13, 2004 11:54 PM|LINK
ssmoot
Participant
1760 Points
352 Posts
Re: Your favorite O/R Mapper?
Dec 14, 2004 03:17 AM|LINK
kevin.weir
Participant
850 Points
170 Posts
Re: Your favorite O/R Mapper?
Dec 14, 2004 05:33 AM|LINK