.net中集中式数据库应用程序的设计/架构建议

Question

我是初级.NET程序员。 我必须开发一种应用程序，该应用程序可以在本地环境中为少数用户（大约8个）处理销售，客户和提供者（还有很多其他事情）。 应该创建一个完整的东西，以便使用集中式数据库在本地使用。 我的架构从上到下都是这样的：

1.Windows窗体上的UI。

2.用于处理用户请求的控制器

3.Bussines对象是Entity Framework生成的对象

4.SQL数据库

显然，我已经知道这不是架构的最佳方法，但我想使其尽可能简单。 我已经做了很多研究，但是问题的数量似乎正在扩大，因此我一直在寻找有关此特定问题的指导，以便在拥有自己喜欢的推荐体系结构后可以专注于研究。 抱歉，我对这个问题不知所措。

Tnx帮助新手。

Answer 1

您所描述的内容似乎是初级开发人员级别的一种好方法。

有许多因素会影响哪种架构适合项目。 与一劳永逸的应用程序相比，时间，进度，金钱，简单性或复杂性，可维护性和将来的开发扩展。 由于数据模型或与某些未知系统的集成，将来的将来版本是否可能需要大量重写？

第一次迭代后，没有应用程序是完美的。 任何优秀的开发人员都会随着技术技能和知识的增长而找到无数种改善项目的方法。

话虽这么说，数据库和实体框架方面的工作还是很不错的。 EF将使您快速专注于功能而不是基础架构。 您可能已经将EF与其他对象模型套件或基于传统存储过程的方法进行了权衡。

UI可能由客户或业务需求决定。 唯一的重大决定可能是Intranet Web应用程序，因此您不必担心在用户计算机上安装软件。

控制器/类库/业务层很有意义，因此您不必直接在Winforms代码中针对EF编写查询。 这使您可以更轻松地提取UI并用其他方式替换。

您所概述的所有内容都会在不知道确切情况的情况下引发任何危险信号。 继续采用这种方法，看看它如何发展。 完成后，请考虑该架构的哪些方面面临挑战，冗余或其他麻烦。

Answer 2

如前所述，由于已生成实体框架对象，因此您可能希望在Controller和Entity对象之间具有一个或多个Model级别。 通常，一个特定的视图具有来自多个实体的数据。 如果您没有控制器可以访问的另一级模型，通常会发生的是将业务逻辑迁移到控制器。

换句话说，控制器将创建模型，并且模型将知道如何与实体进行交互。

请注意，由于您在＃2中引用了Controllers，因此我假设您正在使用MVC模式。