Cliff,
On Mon, Aug 16, 2010 at 23:06, cliff vaughn <[email protected]>wrote:
> 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.
>
Absolutely nothing. That's why we need tests, both for NH and FNH. Even for
Automapping/ConfORM.
> 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?
>
Um... it's part of the default download... right there... in the
"Required_Bins" folder.
> 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. :)
>
That's OK, and it shows the projects are healthy. In my case, I had to use
"advanced" NH functions from day zero (legacy DB), so I'm thankful to have
access to the full NH featur set.
>
>
>> 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.
>
OK, it might save you one test run and Intellisense can save some
keystrokes. Still, I usually copy/paste/regExReplace the names for any class
with more than 5 properties (not trying to "win the argument" here, that's
really what I do)
> 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. :)
>
It's called "xunit" ;-)
Again, *I* don't find any value on a compile-time check that only verifies
that the output XML will be well-formed and with existing property names.
But you have every right to use it if it makes a difference in your
workflow.
> 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...
>
I don't say that particular advantage doesn't exist. Just that it's not that
useful, that it generates a false sense of safety like José said, and that
the cons grossly surpass the pros.
Diego
--
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.
