Thanks Frans for the info about FNH and VB.Net. This is the first material that says it will work and includes some examples
John Davidson On Fri, Aug 13, 2010 at 5:34 AM, Frans Bouma <[email protected]> wrote: > > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
