这是设计N层的正确方法吗？

Question

我打算创建不同的图层，因此在我的Visual Studio项目中，我将：

BusinessLayer： 包含业务对象（实体） 即用户，员工，产品等

DataAccessLayer： 实体框架

演示文稿图层： 观点＆amp;的ViewModels

所以说，例如，我想让用户登录此应用程序。

1. 视图将显示用户界面以输入信息。
2. 当用户按回车键时，执行command =＆gt;视图模型
3. ViewModel将使用Entity Framework从数据库中查询用户数据，然后ViewModel将初始化User对象（来自BusinessObject），并将User数据映射到User对象。
4. 然后，此User对象将存储到静态参数中以供将来使用。

所以我真正关心的是：

1. 这是设计N层的正确方法吗？
2. 我应该将每个图层分配到不同的Visual Studio项目吗？ （即业务对象将在另一个项目内）
3. 让Business Object自行查询数据会更好吗？所以 Business Object construtor会调用实体框架吗？
4. 我应该为使用实体框架编写一个Repository类吗？

我不介意这是否复杂，因为据我所知，这个应用程序将是巨大的。所以我想正确地设计它，使其灵活和可扩展。

任何建议都会很棒，谢谢。

Answer 1

  

1这是设计N层的正确方法吗？

我不会说正确，但适合项目。通过查看提供的问题，在您的设计中看不到太多问题。

  

2我应该将每个图层分配到不同的Visual Studio项目吗？   （即业务对象将在另一个项目中）

当您要在不同的项目/域中重用这些层时，基本上可以做到这一点。想想你正在做什么以及你可能会做什么，并决定这是否是你要做的事情。

考虑到选择使它们成为一个单独的项目，架构变得更复杂，但也更易于扩展。举个例子，您可以为用户提供业务层修复的patch，并且不要安装整个软件包。我重申这是一个选择。在大多数情况下，他们只是选择一次性安装以避免复杂性（依赖关系管理，不同部分之间的版本控制以及所有混乱......）

  

3让Business Object自行查询数据会更好吗？所以   Business Object construtor会调用实体框架吗？

分开Query引擎最好。更可测试和可扩展的架构。

  

4我应该为使用实体框架编写一个Repository类吗？

关于可扩展性的故事。您可以包装EF，在这种情况下，您可以在一天内，当您决定继续（例如）SQLite + ORM，对其进行更改，而不会破坏所有软件基础架构（尽可能自然地）。但是，请注意，实现这一点需要更多时间。

平衡您的资源和时间，并做出更适合您和您的项目的选择。