新的Web项目设计模式规范
我有一个有50多个表的关系数据库。他们有多种类型的关系，一对一，多个。
Code首先或数据库会首先在我将基于此数据库创建的新的MVC项目中更有效吗？
根据最佳实践逻辑，在如此大的（总计20亿+数据）中首选哪一个？
问候..
I have a relational database with more than 50 tables. 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?
According to the best practice logic, which one is preferred in such a large (2 billion+ data in total) place?
Regards..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为，代码首先应该是更好的情况，因为您主要是为应用程序而不是数据构建软件。
“ Code First”是指关注您的问题域和域模型。
访问数据库是持续您的应用程序状态的实现详细信息，不应在软件设计的早期阶段提及。
在域驱动的设计和清洁架构中可以找到类似的概念。
在您的情况下，尽管数据已经存在于数据库中，但主要问题仍然可能是：您的新项目是什么？
案例1：
如果仅仅是为了读取数据，例如演示文稿，那么您可以将数据库中的数据视为数据模型；这可能适合“数据库优先”的概念。但是，由于数据模型是您问题的模型，因此我仍然将其视为代码。
案例2：
另一方面，如果有一些特定的要求，您绝对应该首先构建域模型，以专注于应用程序的要求和问题，而不是数据库。
否则，您可能会发现您的应用程序被数据库的架构粘住，从而导致了复杂的应用程序逻辑，具体取决于问题域和数据之间的差异，因为您的应用程序不是关注问题，而是关注数据。
对于访问数据库，您可能要寻找的是 data mapper模式。除此之外您的域模型。
对于您提到的效率问题：
假设您是前面提到的2个情况。在这种情况下，您可以查看命令查询责任egregation（cqrs）来自命令（更改系统状态的操作）的查询（读取数据的操作）。
将阅读/写作的责任分为您的系统可以提高您应用程序中演示文稿的效率。
总之，如果您不实施仅读取应用程序，则不会使用数据库驱动的设计。
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; 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.
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. Additional to it you could implement the Repository Pattern, which will be designed for the entities in your domain model.
For the efficiency problem you mentioned:
Suppose you are the case 2 mentioned previously. 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).
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.