Blazor WASM与ASP.NET Core间可维护API设计方案咨询

我正在为一个中型项目（数名开发者，预计开发数年）寻求Blazor WebAssembly与ASP.NET Core服务器间API的设计与实现建议。以下是我尝试过的方案及遇到的问题：

方案一：将Entity类放入Shared项目，作为Controller方法返回类型 #

优点 #

• 简洁性：无需样板代码
• 确保从数据库到客户端的类型安全性

缺点 #

• 部分场景下数据需在服务器端处理后返回，例如无需返回每个产品，仅需返回某分类下的产品总数；有时客户端仅需数据模型的简化视图，例如客户端仅需知晓可用价格，但数据库设计更复杂，以便服务器判断不同客户的可用价格。这类场景需为Controller方法创建自定义返回类型（Data Transfer Objects，DTO），导致部分方法返回数据库实体、部分返回DTO的不一致情况，且这类场景十分常见，因此更适合全程使用DTO。
• 客户端通常不会使用实体的所有字段，但仍会传输全部字段，导致网络不佳的用户体验变慢。

方案二：为每个Entity创建一个DTO，通过Entity.ToDataTransferObject()映射 #

Controller包含大量数据查询方法，以适配客户端不同组件的需求。数据库结果通常为Entity或List<Entity>形式。针对每个数据库实体，我们通过entity.ToDataTransferObject()方法将数据库结果转换为Shared项目中的DTO。
当响应类型与数据库实体差异较大时，我们会创建独立的DTO，并在Controller方法或独立类中完成转换。

优点 #

• 客户端数据模型复杂度恰到好处

缺点 #

• 部分Controller方法需加载并返回实体及其关联实体的全部数据（深度达5层），部分方法仅需加载两个简单字段。由于使用同一entity.ToDataTransferObject()方法，需共享同一返回类型，所有不总是返回的字段需声明为可空。这会导致严重问题：编译器无法确保Blazor组件与Controller方法返回类型的兼容性，也无法确保数据库查询与entity.ToDataTransferObject()方法的兼容性，兼容性仅能通过测试发现（且需数据库存在对应数据）。随着应用开发及数据模型演进，这会成为大量bug的来源。
• 多个Controller方法查询相同数据，查询中包含业务逻辑（例如哪些产品应展示给当前客户），导致业务逻辑在多个方法中重复，甚至在其他Controller中重复。

我正在考虑的方案三 #

方案二的缺点促使我考虑以下设计变更：

• 不再将DTO的属性设为可空来表示未从数据库加载，若某属性未加载，则创建不含该属性的新DTO类。
• 不再使用entity.ToDataTransferObject()这一通用转换方法，而是为每种DTO创建独立转换方法。
• 提取EF Core查询的可复用部分，避免业务逻辑重复。

但这会产生大量额外代码，需为实体的每个属性子集（供组件使用）创建新类。虽然这可能消除当前大部分bug，但代价高昂。

请问我是否遗漏了什么？是否有更优的设计方案可供选择？

内容的提问来源于stack exchange，提问作者Draex_