> Fleunt NHibernate is almost a non-starter as there is no documentation on
> how to use it with VB.Net, if it would even work.
One of our support team members, Matt Trinder, had NHibernate
experience and started our NHibernate templates. He wrote ~60% of them, both
FluentNH and Hbm, for C#. I wrote the final 40% and the VB.NET output port.
I had zero experience with nhibernate nor with fluentNH. Everything I know
about hbm and fluentnh mapping comes from docs and some random stackoverflow
posts. When you start from scratch and only a deep knowledge of O/R mapping,
you learn how good/bad docs really are.
Plain and simple: the hbm docs are far from complete. As fluentNH
does what you can do in hbm (without some edge cases no-one really needs),
not knowing what to do with for example a 1:1 fk/uc -pk relationship, it's
impossible to get started with fluentNH, as indeed the docs of it don't
contain info about that. That's IMHO also not what it should contain. It
should contain documentation about how to map the majority of constructs,
and it does that OK-ish, and for the rest you can use the knowledge you gain
from hbm mappings to write code in fluentNH, it's not rocketscience, it's
just a matter of trial/error to get around the incomplete parts of the hbm
mapping docs.
Writing the VB.NET port was easy, except 1 thing: VB.NET doesn't
support anonymous methods which do things. This is a problem when defining
components (value types), as you can't do that inline, you have to write
separate methods to do that and refer to that. This isn't that bad, VB.NET
developers seem to be used to that anyway. That's all there is to it. So I
don't really see where the 'non-starter' comes from, it's really not that
hard. So you get stuff like: (don't mind the .Access.... commands for now)
''' <summary>Represents the mapping Of the 'Customer' entity, represented by
the 'Customer' class.</summary>
Public Class CustomerMap
Inherits ClassMap(Of Customer)
''' <summary>Initializes a New instance Of the <see
cref="CustomerMap"/> Class.</summary>
Public Sub New()
MyBase.New()
Table("[dbo].[Customers]")
DynamicUpdate()
DynamicInsert()
Id(Function(x) x.CustomerId) _
.Access.CamelCaseField(Prefix.Underscore) _
.Column("CustomerID") _
.GeneratedBy.Assigned()
Component(Function(x) x.Address, AddressOf
MapAddressComponent)
...
End Sub
Private Sub MapAddressComponent(toMap As ComponentPart(Of
ValueTypeClasses.AddressVt))
toMap.Map(Function(x)
x.Address).Access.CamelCaseField(Prefix.Underscore)
toMap.Map(Function(x)
x.City).Access.CamelCaseField(Prefix.Underscore)
toMap.Map(Function(x)
x.Country).Access.CamelCaseField(Prefix.Underscore)
toMap.Component(Function(x) x.PostalCode, AddressOf
MapAddressPostalCodeComponent)
toMap.Map(Function(x)
x.Region).Access.CamelCaseField(Prefix.Underscore)
End Sub
Private Sub MapAddressPostalCodeComponent(toMap As ComponentPart(Of
ValueTypeClasses.ZipCodeVt))
toMap.Map(Function(x)
x.Value).Column("PostalCode").Access.CamelCaseField(Prefix.Underscore)
End Sub
very straight forward.
> XML is a lowest common
> denominator type solution and should always be retained. Higher level
> solutions are great, but not always accessible
For backwards compatibility, hbm is indeed not removable, however
the format itself is really complex at times, and leads to trial/error as
much of it seems to be added by various people to solve a problem they were
having and not supporting a generic vision of mapping entities to tables.
A higher level solution which makes the downsides of xml editing go
away is IMHO always preferable. If that's FluentNH, why not embrace it and
make it easier to make that the lowest common denominator. It at the moment
at least solves the problem the hbm files are having: refactoring of
classes.
FB
--
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.
