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