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

Question

我计划创建不同的层，所以在我的 Visual Studio 项目中，我将拥有：

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

数据访问层： 实体框架

表示层： 视图和视图模型

比如说，我想让用户登录到这个应用程序。

1. View 将显示 UI 以让用户输入信息。
2. 当用户按下回车键时，执行命令 => ViewModel
3. ViewModel 将使用 Entity Framework 从数据库中查询 User 数据，然后 ViewModel 将初始化一个 User 对象（来自 BusinessObject ），并将 User 数据映射到 User 对象。
4. 然后此用户对象将存储到静态参数中以供将来使用。

所以我真正关心的是：

1. 这是设计 N 层的正确方法吗？
2. 我应该将每一层分配给不同的 Visual Studio 项目吗？ （即业务对象将在另一个项目中）
3. 让业务对象自己查询数据是不是更好？所以在 业务对象构造器会调用实体框架吗？
4. 我应该写一个 Repository 类来使用实体框架吗？

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

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

Answer 1

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

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

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

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

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

3 让Business Object自己查询数据是不是更好？所以在 业务对象构造器会调用实体框架吗？

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

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

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

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