|
|
Re: What Are Your Java Pain Points, Really?
|
Posted: Feb 21, 2007 11:27 PM
|
|
> > Linq isn't released yet (except for betas), but I
> haven't
> > even used C# yet.
> > I've looked at the examples (found via Wikipedia) and I
> > liked the static typing of SQL
>
> I've used languages that allow embedded SQL. PowerBuilder
> and COBOL for example. The embedded SQL inevitably
> becomes the biggest maintenance problem.
I have also found embedded SQL to be a maintenance problem.
I think the reason being that it cannot be refactored (probably because it is not statically typed). This problem is solved in Linq.
> It's something I
> don't care to suffer through again. Inversion of control
> (no, I don't mean Spring or Hibernate in particular) is a
> much more maintainable approach.
I guess you mean that you change the SQL schema without changing the code.
I think this is only true for trivial schema changes - and that refactoring can do the same for you.
OTOH, Linq can do things that Hibernate cannot do as easily - otherwise you wouldn't need HQL (embedded SQL).
I have to admit that I don't have experience with Hibernate or Linq, though...
> > and indeed the integration
> > with XML (and object querying for that matter). When
> > viewed from the right perspective, SQL and XML are not
> so
> > much different (both are an object graph).
>
> Looking at these examples:
> http://msdn2.microsoft.com/en-us/vcsharp/aa336746.aspx
> LINQ appears to be a rewrite of SQL.
Linq is actually the common part. XLinq is the XML version of Linq. I just found this overview of XLinq (also found if you google for XLinq):
msdn.microsoft.com/VBasic/Future/XLinq%20Overview.doc
In essence, the XLinq objects have methods like descendants, parent, etc. that don't make sense in DLink (database version of Linq)
> In SQL an item from a table called address always has the
> same definition. An item named address in XML could have
> different definitions depending on it's parent elements
> and may not have an definition at all.
True. To solve this you need the same conditionals as in SAX or XQuery.
In Linq, this would look like (from the document above):
If the contact has no phone numbers, the phoneNumbers wrapping element will exist, but there will be no phone child elements. The following example demonstrates how to resolve this situation:
new XElement("contacts",
from c in contacts.Elements("contact")
select new XElement("contact",
c.Element("name"),
c.Elements("phone").Any() ?
new XElement("phoneNumbers", c.Elements("phone")) :
null
)
);
> I've worked with
> XML schemata in the past where there were 5 or 6 distinct
> Address types. An entity like a business partner could
> have 3 distinct addresses of 3 distinct types. Even if
> you use a schema definition (like w3c schema) you can
> allow 'any' elements at any point in the definition of an
> element.
>
> Any non-trivial work with XML is going to require
> transformations.
I just found out that transformation are also supported:
(from the document found above)
new XElement("Customers",
from c in contacts.Elements("contact")
select new XElement("Customer",
new XElement("Name", (string) c.Element("name")),
new XElement("PhoneNumbers",
from ph in c.Elements("phone")
select new XElement("phone", (string) ph,
ph.Attribute("type")
)
)
)
);
|
|
Previous Topic
