FluentNHibernate 工作单元/存储库设计模式问题
我想我现在陷入了僵局。我有一个使用 FluentNHibernate (ORM) / SQLite (文件 db) 从头开始构建的应用程序。我决定实施工作单元和存储库设计模式。我现在需要考虑最终的结果，它将作为 WPF Windows 应用程序（使用 MVVM）开始，并最终实现 Web 服务/ASP.Net 作为 UI。
现在我已经为 ORM 创建了域对象（实体）。现在我不知道应该如何在 ORM 之外使用它。关于它的问题包括：
- 我应该直接使用 ORM 实体对象作为 MVVM 中的模型吗？如果是，我是否将业务逻辑（例如某些值必须为正且大于另一个属性）放入这些实体对象中？这当然是一种更简单的方法，也是我现在倾向于的方法。然而，是否会有一些陷阱会破坏这个计划呢？
- 如果上面的答案是否定的，那么我是否需要创建一组新的类来实现业务逻辑并将它们用作 MVVM 中的模型？我将如何处理模型对象和实体对象之间的转换？我想类型转换器的实现在这里会很好用。
I think I am at a impasse here. I have an application I built from scratch using FluentNHibernate (ORM) / SQLite (file db). I have decided to implement the Unit of Work and Repository Design pattern. I am at a point where I need to think about the end game, which will start as a WPF windows app (using MVVM) and eventually implement web services / ASP.Net as UI.
Now I already created domain objects (entities) for ORM. And now I don't know how should I use it outside of ORM. Questions about it include:
- Should I use ORM entity objects directly as models in MVVM? If yes, do I put business logic (such as certain values must be positive and be greater than another Property) in those entity objects? It is certainly the simpler approach, and one I am leaning right now. However, will there be gotchas that would trash this plan?
- If the answer above is no, do I then create a new set of classes to implement business logic and use those as Models in MVVM? How would I deal with the transition between model objects and entity objects? I guess a type converter implementation would work well here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要回答您问题的第一部分，是的，您的业务逻辑和验证应该放在您的实体中。 NHibernate 的目的是让您将实体设计为持久性无知的。这意味着只要有可能，您就应该按照不关心持久性的方式来设计实体。这并不完全可行，您很快就会发现（您需要使属性虚拟化以支持延迟加载，如果您想使用 NHibernate Validator，您将使用验证属性来装饰您的属性），但是在大多数情况下，NHibernate 都能很好地避免妨碍您。
至于是否使用您的实体作为模型，您会得到不同的评论。理想情况下，您将创建单独的视图模型类并将实体映射到视图模型，以便您的视图只能访问它们所需的最少信息。这对于防止 N+1 访问问题。然而，这样做往往会带来巨大的痛苦。当然，有像 AutoMapper 这样的工具可以更轻松地将实体属性转换为视图模型。
To answer the first part of your question, yes your business logic and validation should go in your entities. The point of NHibernate is to let you design your entities to be persistence ignorant. That means that you should, whenever possible, be designing your entities as you would if you didn't care about persistence. This isn't entirely feasible as you'll soon find out (you'll need to make your properties virtual in order to support lazy loading and if you want to use NHibernate Validator you'll be decorating your properties with validation attributes), but for the most part NHibernate does a good job of staying out of your way.
As for whether to use your entities as the models, you'll get mixed reviews on that. Ideally, you would create separate viewmodel classes and map from your entities to the viewmodel so that your views will only access to the bare minimum of information they need. This also goes a long way in preventing N+1 access issues. However, doing so is often a huge pain. Granted, there are tools like AutoMapper that will make it easier from transposing your entity properties to a viewmodel.