我通过WCF服务公开了一些CRUD方法，因为一些数据对象通过NHibernate持久保存在数据库中。将NHibernate类用作数据契约是一种好方法，还是更好地将它们包装起来或用其他一些数据契约替换它们？你的方法是什么？
答案 0 :(得分：6)
我们的团队花了几个月时间讨论这个设计点，所以我有很多链接要分享; - ）
简短回答：您应该“从”NHibernate类转换为域模型。
答案很长：我认为答案就是原则问题。如果曾想要可互操作，则不使用数据集作为您的DTO（I love Hanselman's post on this）。我不是说这从来不是一个好主意;显然，人们已经取得了成功。只要知道你正在偷工减料，这是一个冒险的主张。
如果您可以完全控制将数据推入的类，则可以构建一个不错的域模型，并将NHibernate数据映射到这些类中。你很可能会遇到严重的问题，就像IList＆lt;＆gt; （＆lt; bag＆gt;映射到的）不可序列化。您必须编写自己的序列化程序，或使用类似NetDataContractSerializer的内容，但却失去了互操作性。
您需要衡量构建一些包装类所涉及的工作量，以及它们之间的转换，但是您可以完全灵活地使用您的域模型。然后，您就可以像NHibernate地图和对象一样（就像我们所做的那样）做代码生成。然后，您的数据合同将作为数据的抽象，就像它们应该的那样。
P.S。您可能需要查看ADO.NET Data Services，这是一种公开数据的RESTful方式，此时，这似乎是公开数据的最具互操作性的选择。
答案 1 :(得分：1)
您不希望直接公开您的域模型，而是在访问进程边界时将域映射到某种类型的消息。您可以利用NHibernate为您完成映射工作。在这种情况下，您将有2个映射，一个用于域模型，另一个用于轻量级消息。
答案 2 :(得分：0)
我没有这方面的直接经验，但我之前通过WCF发送了数据集，并且工作得很好。我认为将NHibernete用作WCF上的数据对象的最大问题是缺乏互操作性（使用数据集的情况也是如此）。客户端不仅必须使用.NET，客户端还必须使用NHibernate。这违反了SOA原则，但如果您确定肯定您将不会重复使用此组件，那么就没有理由不这样做。
至少值得一试。