BLL 和 DAL 中的不同模型答案

【问题标题】：Different models in both BLL and DALBLL 和 DAL 中的不同模型
【发布时间】：2015-05-13 09:17:04
【问题描述】：

因此，我正在尝试学习如何在 WPF 应用程序中保持良好的结构，并且很难找出使用 BLL 和 DAL 的最佳方式。

我的 BLL 中已经有几个模型，例如：

客户，帐户，等等

我还使用 MVVMLight 工具包让事情变得更简单，所以我的几乎所有模型都继承自“ObservableObject”。

现在我要创建 DAL 并使用实体框架。由于我所有的模型都使用 ObservableObject 我觉得我不能只将它们移动到我的 DAL 来创建我的表（代码优先）。

最好的方法是在我的 DAL 中创建几乎相同的对象，并在检索时将所有数据映射到 BLL 中的旧模型？我知道这有点双倍的工作，所以但看不出我怎样才能让它更干净（除了停止从 ObservableObject 继承）

【问题讨论】：

对于不熟悉上述缩写的任何用户，BLL 代表业务逻辑层，DAL 代表数据访问层。
通常，从 DAL 生成的对象应该不在 BLL 中使用，因此应该复制到 BLL 对象。请注意，您在两层中的对象不应真正几乎相同...您的业务对象应该（或至少可以）是分层的，不像您的 DAL 对象。
我明白了，是的，那我就在正确的轨道上。我对此有一个简短的后续问题，是否有任何正常的命名约定？我想在 DAL 和 BLL 中都有“客户”可能会有点混乱。有像 CustomerBll、CustomerDto 这样的东西是正常的吗？
一个是域/BLL 的 CustomerEntity 和 DAL 的任何表名（特别是如果您使用实体框架）
我个人将 Db 添加到我的 DAL 类的前面以避免该问题，例如。 DbUser，但你可以使用任何你觉得舒服的东西。

标签： c# wpf data-access-layer bll

【解决方案1】：

像Customer 和Account 这样的实体必须属于Domain 模型。建议让您的Domain 与所有不相关的依赖项（例如 MVVM-blablabla）无关。我会首先考虑如何从您的模型中删除对 MVVMLightToolkit 的依赖。您总是可以依赖 INotifyPropertyChanged，有时最好牺牲一些语法片段。如果你能避免重复，你应该避免它。

最后，你提出的问题很大程度上取决于具体情况，没有一种完美的补救措施。

考虑学习以下材料：
domain-driven-design-fundamentals
Eric Evans book on DDD

【讨论】：

感谢您的评论，稍后我将查看复数视觉视频。我知道我可以删除它们，但我觉得我失去的比从中获得的更多。我喜欢 WPF 的地方是易于绑定到 GUI，我宁愿拥有多个模型，也不愿尝试设置新事件等以保持 GUI 更新。
这意味着您的域与 WPF 基础架构紧密耦合。这通常是一个非常糟糕的主意。