数据库列为常量值,而无需在实体类中通过代码进行映射的属性 [英] database column to constant value without the need for a property in the entity class with mapping by code

查看:118
本文介绍了数据库列为常量值,而无需在实体类中通过代码进行映射的属性的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

除了使用NH的按代码映射外,这与此问题几乎相同.

this is almost the same as this question except using NH's mapping-by-code.

我真的需要虚拟属性,因为我还想使用SchemaExport为不同的rdbms创建数据库,而无需为每个rdbms创建/维护脚本.

I really need the virtual properties because i also want to use SchemaExport to create the database for different rdbms without the need to create/maintain scripts for each.

也许有一个MbC专家知道如何使用MbC

Maybe there is a MbC Guru who knows how to do it with MbC

更新:显而易见的简单代码

Update: the obvious simple code

Property("dummyProperty", c =>
{
    c.Column("legacyColumn");
    c.Access(typeof(MyPropertyAccessor));
});

不起作用

NHibernate.MappingException: Unable to instantiate mapping class (see InnerException): Test.MbC.GroupMap ---> System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> NHibernate.MappingException: Member not found. The member 'dummyProperty' does not exists in type Test.Data.Group
   bei NHibernate.Mapping.ByCode.Impl.CustomizersImpl.PropertyContainerCustomizer`1.GetPropertyOrFieldMatchingNameOrThrow(String memberName)
   bei NHibernate.Mapping.ByCode.Impl.CustomizersImpl.PropertyContainerCustomizer`1.RegisterNoVisiblePropertyMapping(String notVisiblePropertyOrFieldName, Action`1 mapping)
   bei 
   ...

也不这样做,因为上帝知道为什么 MbC通过反射内部检查该属性确实存在于类中.

neither does this, because god knows why MbC checks internally with reflection, that the property does exist on the class.

var parameter = Expression.Parameter(typeof(T), "x");
Expression body = Expression.Property(parameter, new GetterPropertyInfo(typeof(T), defaultgetter));
body = Expression.Convert(body, typeof(object));

var lambda = Expression.Lambda<Func<T, object>>(body, parameter);

Property(lambda, m =>
{
    m.Column(defaultgetter.PropertyName);
    m.Access(propertyAccessorType);
});

甚至通过覆盖ClassMapping中的RegisterProperty()来禁用反射测试,在构建hbm抱怨时仍然会抛出该错误:

and even disabling the test with reflection through overriding RegisterProperty() in ClassMapping it still throws while building the hbm complaining:

System.ArgumentOutOfRangeException: Can't add a property of another graph
Parametername: property
   bei NHibernate.Mapping.ByCode.Impl.AbstractBasePropertyContainerMapper.Proper
ty(MemberInfo property, Action`1 mapping)
   bei NHibernate.Mapping.ByCode.ModelMapper.MapProperty(MemberInfo member, Prop
ertyPath propertyPath, IMinimalPlainPropertyContainerMapper propertiesContainer)

   bei NHibernate.Mapping.ByCode.ModelMapper.MapProperties(Type propertiesContai
nerType, IEnumerable`1 propertiesToMap, IPropertyContainerMapper propertiesConta
iner, PropertyPath path)
   bei NHibernate.Mapping.ByCode.ModelMapper.MapProperties(Type propertiesContai
nerType, IEnumerable`1 propertiesToMap, IPropertyContainerMapper propertiesConta
iner)
   bei NHibernate.Mapping.ByCode.ModelMapper.MapRootClass(Type type, HbmMapping
mapping)
   bei NHibernate.Mapping.ByCode.ModelMapper.CompileMappingFor(IEnumerable`1 typ
es)

通过代码映射应该比FNH更灵活?在哪里?

Mapping by code should be more flexible than FNH? Where?

推荐答案

在花了很多时间试图在MbC中进行这种相当简单的映射后,我承认并再次将MbC投入使用.

After investing a lot of time trying to do this rather simple mapping in MbC i concede and throw aboard MbC again.

如此灵活的MbC甚至无法实现像这样的简单映射

Even simple Mapping like this is not remotely possible with the oh so flexible MbC

public class MyClassMap : ClassMap<MyClass>
{
    public MyClassMap()
    {
        Map(x => this.VirtualProp, "legacyColumn").Default("123").Access.None();
    }

    public long VirtualProp { get; set; }
}

这里的优点是我可以使用SchemaExport为旧版应用程序创建兼容的模式,而不会污染我的域类

the advantage here is that i can use SchemaExport to create a compatible schema for the legacy app without polluting my domain classes

这篇关于数据库列为常量值,而无需在实体类中通过代码进行映射的属性的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆