我是一名初级 .NET 程序员。我必须开发一个应用程序，在本地环境中为少数用户（大约 8 个）处理销售、客户和供应商（还有很多事情）。应该使用集中式数据库创建整个内容以供本地使用。我的架构从上到下都是这样的：
1.Windows窗体上的UI。
2.处理用户请求的控制器
3.Bussines 对象是实体框架生成的对象
4.SQL数据库。
显然我已经知道这不是架构的最佳方法，但我希望它尽可能简单。我已经做了很多研究，但是问题的数量似乎越来越多，所以我一直在寻找针对这个特定问题的一些指导，这样我就可以在获得我觉得很舒服的推荐架构后专注于研究。很抱歉提出这个问题，我只是对选项感到不知所措。
Tnx 帮助新手。
正如您所说，生成了实体框架对象，您可能希望在控制器和实体对象之间具有一个或多个模型级别。一个特定的视图通常具有来自多个实体的数据。如果您没有控制器可以访问的其他级别的模型，通常会发生业务逻辑迁移到控制器。
换句话说，控制器将创建模型，模型将知道如何与实体交互。
请注意，我假设您使用的是 MVC 模式，因为您在 #2 中引用了控制器。
您所描述的似乎是初级开发人员级别的好方法。
有许多因素会影响适合项目的架构。与一次性应用程序相比，时间、进度、金钱、简单性或复杂性、可维护性和未来开发扩展。由于数据模型或与某些未知系统的集成，未来的版本是否可能需要大规模重写？
在第一次迭代之后，没有任何应用程序是完美的。随着技术技能和知识的增长，任何优秀的开发人员都会在项目完成后找到无数种改进项目的方法。
话虽如此，数据库和实体框架方面的东西非常好。EF 将使您快速专注于功能而不是基础设施。您可能已经将 EF 与其他对象模型套件或基于传统存储过程的方法进行了权衡。
UI 可能由客户或业务需求决定。这里唯一的另一个重大决定可能是 Intranet Web 应用程序，因此您不必担心在用户计算机上安装软件。
控制器/类库/业务层很有意义，因此您不必直接在您的 winforms 代码中编写针对 EF 的查询。这使您可以更轻松地删除 UI 并将其替换为其他内容。
在不知道确切情况的情况下，您概述的任何内容都不会引发任何危险信号。继续采用这种方法，看看它是如何进行的。完成后，请考虑架构的哪些方面难以处理、冗余或其他麻烦。