在 Fluent NHibernate 中将 URI 映射到字符串
(请参阅此有关 LINQ 的相关问题- to-SQL)
我想使用 NHibernate 将具有 URI
成员的类映射到 string
列。 我究竟怎样才能做到这一点?
我认为相关问题的解决方案在这里不起作用 - 我无法声明私有字段并映射它,因为映射需要引用该字段。
(See this related question for LINQ-to-SQL)
I'd like to map a class that has a URI
member to a string
column using NHibernate.
How exactly might I accomplish that?
I don't think the solution given to the related question works here - I can't declare a private field and map it, because the mapping needs to reference that field.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
除非你需要做一些特殊的事情,否则 NHibernate 提供的
UriType
就可以工作(我不知道它是引入的哪个版本 - 我使用的是 3.1.4000)。无需编写自定义用户类型。ClassMap
您可以在
ClassMap<>
中指定UriType
:属性约定
您可以使用属性约定来映射所有
Uri
属性以使用UriType
:存储为 varchar
如果您想将数据库中的
Uri
存储为varchar
而不是默认的nvarchar
,您可以创建一个派生自UriType
的自定义类型并指定AnsiString
SQL 类型:Unless you need to do something special,
UriType
provided by NHibernate will work (I don't know what version it was introduced - I am using 3.1.4000). No need to write a custom user type.ClassMap
You can specify
UriType
in aClassMap<>
:Property Convention
You can use a property convention to map all
Uri
properties to useUriType
:Storing as varchar
If you want to store the
Uri
in the database asvarchar
rather than the defaultnvarchar
you can create a custom type that derives fromUriType
and specifies theAnsiString
SQL type:同样的解决方案也可以很好地工作;您可以将字符串属性定义为私有,这样它就不会暴露给任何人。
Fluent NHibernate 不像标准 HBM 文件那样容易处理这个问题,但可以通过几种方法来完成。有关说明,请参阅 Fluent NHibernate Wiki。
或者,我认为您必须定义一个可以将值加载/保存为字符串的 IUserType 类。使用 Fluent NHibernate 执行此操作的示例可以在 在这篇博文的末尾。
The same solution would work fine; You could define the string property as private so it is not exposed to anyone.
Fluent NHibernate doesn't handle this as easily as standard HBM files, but it can be done a few ways. See the Fluent NHibernate Wiki for instructions.
Alternatively, I think you'd have to define an IUserType class that can load/save the value as a string. Example of doing this with Fluent NHibernate can be found at the end of this blog post.