简体繁体 English

新的 Web 项目设计模式规范

[英]New web project design pattern specification

原文 2022-06-09 11:40:13 3 1 model-view-controller/ design-patterns/ code-first/ software-design/ database-first

I have a relational database with more than 50 tables.我有一个包含 50 多个表的关系数据库。 They have more than one type of relationship, one to one, more than one.他们有不止一种关系，一对一，不止一种。

Will code first or database first be more effective in the new MVC project I will create based on this database?在我将基于此数据库创建的新 MVC 项目中，代码优先还是数据库优先会更有效吗？

According to the best practice logic, which one is preferred in such a large (2 billion+ data in total) place?根据最佳实践逻辑，在如此庞大（总共 20 亿+ 数据）的地方首选哪一个？

Regards..问候..

1 个解决方案

In my opinion, code first should be the better case in general since you are mostly building the software for application, not data.在我看来，代码优先通常应该是更好的情况，因为您主要是为应用程序构建软件，而不是数据。 "Code first" means to focus on your problem domain and domain model. “代码优先”意味着专注于您的问题域和域模型。 Accessing the database is an implementation detail for persisting your application states and should not be mentioned in the early phase of software design.访问数据库是持久化应用程序状态的实现细节，不应在软件设计的早期阶段提及。

Similar concepts can be found in Domain-Driven Design and Clean Architecture.类似的概念可以在领域驱动设计和清洁架构中找到。

In your case, although the data already exists in the database, the main question could still be: what is your new project for?在您的情况下，尽管数据已经存在于数据库中，但主要问题仍然是：您的新项目是做什么用的？

Case1: If it's simply for reading the data, such as presentation, then you could consider the data in the database as your data model;案例1：如果只是为了读取数据，比如展示，那么你可以把数据库中的数据作为你的数据模型； which might fit in the concept of "database-first".这可能符合“数据库优先”的概念。 However, since the data model is the model for your problem, I would still consider it as code first.但是，由于数据模型是您的问题的模型，我仍然会首先将其视为代码。

Case2: On the other hand, if there are some specific requirements, you should definitely build your domain model first to focus on the requirements and problems of your application rather than the database.案例2：另一方面，如果有一些特定的需求，你绝对应该首先建立你的领域模型，专注于你的应用程序的需求和问题，而不是数据库。 Otherwise, you might find your application is stuck by the schema of your database, resulting in complex application logic, depending on how much difference between your problem domain and your data, since your application is not focusing on the problem but on the data.否则，您可能会发现您的应用程序被数据库的架构卡住，从而导致复杂的应用程序逻辑，具体取决于您的问题域和数据之间的差异，因为您的应用程序不是关注问题而是关注数据。 For accessing the database, what you might be looking for is the Data Mapper pattern .对于访问数据库，您可能正在寻找的是Data Mapper 模式。 Additional to it you could implement the Repository Pattern , which will be designed for the entities in your domain model.除此之外，您可以实现Repository Pattern ，它将为您的域模型中的实体设计。

For the efficiency problem you mentioned:对于你提到的效率问题：
Suppose you are the case 2 mentioned previously.假设您是前面提到的案例 2。 In that case, you can take a look into command query responsibility segregation(CQRS) , which isolated the query (the operations for reading data) from the command (the operations that change the system state).在这种情况下，您可以查看命令查询职责分离（CQRS），它将查询（读取数据的操作）与命令（更改系统状态的操作）隔离开来。 Separating the responsibility of reading/writing to your system could improve the efficiency of the presentation in your application.将读取/写入的职责分离到您的系统可以提高应用程序中演示的效率。

In conclusion, no database-driven design if you are not implementing a read-only application.总之，如果您不实现只读应用程序，则没有数据库驱动设计。