Diego,
On Mon, Aug 16, 2010 at 8:34 PM, Diego Mijelshon <[email protected]>wrote:
> Cliff,
>
> I read your line, is exactly like mine, with a different syntax. And I get
> the same design-time help that you did: intellisense and validation (I just
> have to add the xsd to my solution)
>
> Well, not exactly like yours. One is C# and the other is XML, but i get
it.
> And you're wrong: it's very easy to create incorrect mappings with
> FNH. This is an example I've seen a thousand times:
> Class:
> public AnotherEntity Reference {get;set;}
> Mapping:
> Property(x => x.Reference);
>
And, pardon my ignorance, but what prevents a person from making the same
mistake in xml.
>
> There are TWO errors there. First, you have to use Reference (many-to-one
> in xml) for many-to-one relationships, and the property is not virtual.
> Without the test, building the session factory will fail at runtime. What
> did FNH do for me here? Nothing that the xsd wouldn't have done.
>
FNH at least makes sure you have the word "Reference" correct for the xml.
It's a small thing, i know, but kinda important, wouldn't you agree. Again,
pardon my ignorance, but I didn't know NH provided an out-of-the-box xsd
that could that kind of checking, making sure my property and class names
were right, for my model. Could you point me to that xsd for my current
project?
>
> If you don't like xml (hey - I'm not in love with it either, JSON/YAML look
> beter; it just gets the job done), that's fine, but it's just a matter of
> taste. And you have to deal with all the renamed concepts whenever you ask
> for help, plus it does _not_ support everything that NH does.
>
ok, agree. but not every one needs it to support every nook and cranny of
goodness that NH provides. FNH is growing though. :)
> Just don't say it has an advantage over XML, because that's just not true.
> The only thing it does is check property names.
>
it does still have an advantage, albeit a small one, in that at least it
helps get the class name, property name, and potentially, the DB column name
matching the real class. This is, of course, without relying on a test
run. An example I've seen a thousand times is the xml mappings having the
wrong fully qualified class name in it. I've never run into that with FNH
yet.
>
> As for removing "layers"... well, you should STILL have tests in your
> solution, including at least one for each nontrivial query.
>
Agreed. Never said i wouldn't have tests, just that "IF" i didn't, there'd
be a little comfort there.
> If you think adding FNH will "free" you from that... well, that's just
> naive.
>
Well, assuming a person was knowledgeable in both the xml and FNH, i think
FNH would provide an ever-so-slight advantage, IMHO. But your points are
noted and I don't think the "naive" comment is fair hear. Again, i'm not
trying to be right, but i get the impression you are, so, ok, you're right.
you win. none of my arguments have merit and it's just a matter of taste.
BTW, can you provide a link to the IDE you're using that has that ability to
compile time check your NH xml mappings with your C# class and property
names? I'd like to give it a test drive. :)
> For the record, I'm NOT saying tests are the solution to all your problems
> (they aren't). But NOT HAVING THEM is a much bigger problem.
>
Agreed. no dispute there.
>
> Diego
>
>
I'm sure we could keep going tit-for-tat, here, but I just wish you would
admit that there are some valid points listed above and they do provide some
sort of advantage of xml. FNH doesn't suit your taste, that's fine, but it
does provide an advantage, no, um, validation feature, that you don't
inherently get with xml out of the box when it comes to mapping classes. Oh
well...
--
thanks
cliff
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
