Perhaps it's already this way and this will be redundant to post other
than to clear up confusion about how to acheive this functionality,
from my working with FH and specifically with trying to do more with
automapping I really want to see this project flourish as the
combination of FH+NH truly offers the potentially of killing the
database almost to the point where it's a stupid property bag (as it
should be) and make it so easy to write DDD data layers with almost
zero need to write specific logic for each entity in you data layer.
The biggest stepping stone I've been noticing is the support for
variance in classes in the same assembly. I am working on trying to
produce a fairly robust MVP ASP.NET web framework that is ran through
Unity for DI and FH-NH to not need to write a single line of sql for
the DAL and hopefully be able to write it without needing to write
tons of mapping that has plagued software developers forever.
Currently I'm layering this over the AdventureWorks database that has
a rather dumb naming scheme (which is a perfect choice for my project
since it seems almost all databases have an equally as dumb naming
scheme.)
In my class that manages NH I have this block of code:
var persistenceModel =
AutoPersistenceModel.MapEntitiesFromAssemblyOf<Employee>
()
.Where(t => t == typeof (Employee))
.WithConvention(convention =>
convention.GetPrimaryKeyName = prop => prop.Name + "ID")
.WithConvention(convention => convention.GetTableName
= prop => "HumanResources.v" + prop.Name)
However the conventions I need to also handle the Vendor class would
be similar to
var persistenceModel =
AutoPersistenceModel.MapEntitiesFromAssemblyOf<Vendor>
()
.Where(t => t == typeof (Vendor))
.WithConvention(convention =>
convention.GetPrimaryKeyName = prop => prop.Name + "ID")
.WithConvention(convention => convention.GetTableName
= prop => "Purchasing.v" + prop.Name)
Now I think if I followed this pattern creating a bunch of models I
could eventually merge all of these models together into a single
model somehow but I propose a scheme similar to this
var persistenceModel =
AutoPersistenceModel.MapEntitiesFromAssemblyOf<Employee>
()
.Where(t => t.Namespace == "Domain.Business")
.WithGlobalConvention(convention =>
convention.GetPrimaryKeyName = prop => prop.Name + "ID")
.WithConventionWhere(convention =>
convention.GetTableName = prop => "HumanResources.v" + prop.Name, t =>
t == typeof (Employee))
.WithConventionWhere(convention =>
convention.GetTableName = prop => "Purchasing.v" + prop.Name, , t => t
== typeof (Vendor))
Unless this can already be achieved by the ordering of the .Where
and .WithConvention statements (which would be quite confusing given
the fluent interface scheme) I think creating the ability to more
directly link a convention to a specific clause whether it's a single
object type or a namespace etc that is already supported in the .Where
statement at a global level in the model would be a very important
addition.
Part of me would like to have it jsut be .WithConvention<Vendor>
(convention => convention.GetTableName = prop => "Purchasing.v" +
prop.Name) but i feel having to tie it specifically to a class would
lessen the flexibility of it much more than the Where statement that
takes in the Func parameter.
The only part I see to this is the potential for the complexity to
ramp up significantly since it doesn't appear the API currently could
support linking a where clause and convention clause together. I think
if the API could support a feature similar to this it would allow the
majority of all users to have 1 big ugly block where they define their
persistence model and not need to write any other database specific
code unless they do major schema changes.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Fluent NHibernate" group.
To post to this group, send email to fluent-nhibernate@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/fluent-nhibernate?hl=en
-~----------~----~----~----~------~----~------~--~---
