2

我正在编写一个类库作为 DataModel。DataModel 能够处理所有与数据库相关的任务。我同样使用 NHibernate 和 Fluent NHibernate。

现在出现的问题如下：

  1. 我们是否应该公开实体（POCO 类）。
  2. 拥有一个具有内部受保护属性和作为接口公开的属性的实体是否很好。
  3. 为映射创建的实体可以是 WPF MVVM 的模型。
  4. 还是我们应该直接绑定实体？
  5. 如果库返回实体列表作为 API 返回，则无法控制。所以任何人都可以在列表中添加或删除。我应该如何控制它。我是否应该创建从 IList 派生的代理来跟踪它。
  6. 抛出 API 中发生的异常是否正确，还是应该返回 null？
  7. 继续登录图书馆好吗？
4

2 回答 2

1

我们是否应该公开实体（POCO 类）。

是的，创建包装类需要更多的努力。

拥有一个具有内部受保护属性和作为接口公开的属性的实体是否很好。

是的，Setter 和非公开属性是可控的。

为映射创建的实体可以是 WPF MVVM 的模型。

对于原始类型可以，但引用可以通过接口公开。

还是我们应该直接绑定实体？

如果 Model 是直接使用 POCO 对象创建的。对于刷新情况，它更加灵活。如果存在取消操作，用户无法更改 POCO 对象的属性。

如果库返回实体列表作为 API 返回，则无法控制。所以任何人都可以在列表中添加或删除。我应该如何控制它。我是否应该创建从 IList 派生的代理来跟踪它。

IEnumerable 用于通过接口公开集合。

抛出 API 中发生的异常是否正确，还是应该返回 null？

异常更好地让用户了解错误。但将异常包装在用户可读而不是返回 NHibernate 异常中。

继续登录图书馆好吗

日志记录是了解问题的非常好的功能。

于 2013-05-31T09:58:27.980 回答
1

我们是否应该公开实体（POCO 类）。

是的，否则当没有人使用时实体的用途是什么

拥有一个具有内部受保护属性和作为接口公开的属性的实体是否很好。

这取决于！使用 ORM 时，内部受保护的属性没有问题，但我更喜欢将内部内容减少到最低限度，因为我喜欢保持自己状态的对象。接口很好

为映射创建的实体可以是 WPF MVVM 的模型。

当然。无需再次复制它们。这就是持久性无知的目的

还是我们应该直接绑定实体？

通常，UI 要求与持久性/业务规则有很大不同，因此会有专门的 ViewModel 用于 UseCases/Views。然而像Order class扔进列表这样的简单数据持有者可以直接绑定（例如使用DatabindingFactory使它们实现 INPC）

如果库返回实体列表作为 API 返回，则无法控制。所以任何人都可以在列表中添加或删除。我应该如何控制它。我是否应该创建从 IList 派生的代理来跟踪它。

列表只是在内存容器中。用户仍然需要通过 API 来保存/更新状态。

抛出 API 中发生的异常是否正确，或者我应该返回 null

如果返回集合，则空集合比 null 好得多。

然而，异常应该冒泡，最好包裹在自己的可处理异常中。实施NHibernate.Exceptions.ISQLExceptionConverter（例如 like NHibernate.Test.ExceptionsTest.MSSQLExceptionConverterExample）并使用例如配置它 config.DataBaseIntegration(db => db.ExceptionConverter<MyExceptionConverter>())

继续登录图书馆好吗

绝对。日志记录可以调试已部署的应用程序。(Fluent)NHibernate 已经有很多内置的日志记录，如果可能的话。

于 2013-05-03T14:35:20.533 回答