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

Question

我计划创建不同的图层，因此在我的 Visual Studio 项目中，我将:

业务层: 包含业务对象(实体) 即用户、员工、产品等

数据访问层: Entity Framework

表示层: View 和 View 模型

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

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

所以我真正关心的是:

1. 这是设计 N 层的正确方法吗？
2. 我应该将每一层拆分到不同的 Visual Studio 项目中吗？ (即业务对象将在另一个项目中)
3. 让 Business Object 自行查询数据是否更好？所以在 业务对象构造器将调用 Entity Framework ？
4. 我应该写一个 Repository 类来使用 Entity Framework 吗？

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

任何建议都很好，谢谢。

Answer 1

1 Is this correct way to design N-layers?

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

2 Should I sperate each layers to different Visual Studio project? (i.e Business objects will be inside another project)

基本上，当您要在不同的项目/域中重用这些层时，这样做是有道理的。考虑一下您正在做的事情以及您可能将 做的事情，然后决定这是否是您要做的事情。

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

3 Is it better to let Business Object to query the data it self? So in Business Object construtor will calls entity framework?

最好有分离的查询引擎。更具可测试性和可扩展性的架构。

4 Should I write a Repository class for use entity framework?

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

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