我正试图了解GraphQL和我刚刚观看的HotChocolate演示。以下是我认为的好处：
- 客户端可以请求任何字段组合，从而提供最大的灵活性
- 查询直接转换为SQL，从而获得高性能和少量开销
如果你愿意，我的问题或担忧是：这不是在几乎肯定会在某个时候中断的级别上将我的API与数据库耦合在一起吗？如果我需要调整我的数据库模式，事情就会崩溃。这种担忧有效吗？
Hot Chocolate或GraphQL通常只是现有API之上的一个小包装器。
演示中显示的解析器
[UseProjection]
// ...
public IQueryable<Entity> GetEntities(DbContext context) => context.Entities;
也可以是现有服务之上的一个小包装器，例如存储库。
public List<Entity> GetEntities([Service] IService service)
=> service.GetEntities();
链接演示中显示的数据中间件允许人们开始使用尽可能少的样板和尽可能高效的数据中间件，但它本质上与GraphQL的预期相冲突
这最终是每个开发人员必须自己决定的一种权衡。有了Hot Chocolate，数据中间件确实很强大，但它引入了耦合，也有其局限性。另一方面，你获得了快速移动的能力，效率高，避免了通常需要的大量样板。
当然，你也可以自由选择更传统的路线，有更多的样板，但要解耦。在这种情况下，GraphQL只是作为一个薄薄的API层，正如它所预期的那样。
我认为这就是GraphQL的美妙之处，您可以选择GraphQL服务器，并能够连接几乎任何数据源或服务。
关于您对数据库迁移破坏数据中间件的担忧。这是有效的，但大多数时候，Hot Chocolate非常聪明地选择新字段并正确连接它们，而无需编写任何额外的代码。
使用HotChocolate，您可以选择以各种方式和方法进行设计，如模式优先、代码优先或基于注释。
从体系结构的角度来看，您可以使用干净的体系结构，很好地分层应用程序，然后在它上面放一层薄薄的GraphQL
但许多开发人员确实希望快速开发，他们将数据库直接公开。
热巧克力允许你做任何你想做的方法。热巧克力核心实际上对数据库或实体框架一无所知。为了获得投影功能，您需要选择使用HotChocolate.Data.*软件包。
热巧克力不需要数据库或任何其他层之间的任何紧密耦合。