在ASP.NET Core 8中仅用一个ViewComponent类的弊端咨询

• 类型安全完全缺失
  使用dynamic类型传递参数，编译阶段无法校验参数的类型、字段名是否正确，只有运行时才会暴露错误。比如调用时把paramData里的Provider写成provider，或者组件视图里引用了不存在的字段，编译器不会给出任何警告，排查问题成本高。同时组件视图依赖元组模型，元组的字段名是编译时确定的，一旦参数结构变更，视图中的引用不会自动更新，容易引发隐性bug。

• 丢失ViewComponent的核心特性
  官方ViewComponent支持依赖注入，每个组件可以按需注入专属服务，而这种单类方案下，所有组件的依赖都必须在AppViewComponent中统一添加，导致类的职责膨胀、耦合度极高；另外官方支持异步InvokeAsync方法，方便处理数据库查询等异步操作，单类方案无法为不同组件单独定义异步/同步逻辑，灵活性极差。

• 维护性与扩展性差
  所有组件的调用逻辑都绑定到这一个类上，一旦AppViewComponent出现问题，所有组件都会受影响。如果某个组件需要参数校验、数据预处理等逻辑，无法封装在组件自身（因为没有独立的类），只能在调用处或视图中编写，代码分散，违反关注点分离原则。后续新增复杂组件时，这种单类结构会越来越臃肿，难以维护。

• 路径硬编码带来的脆弱性
  视图路径采用硬编码的方式/Views/{baseFolder}/Components/{componentName}.cshtml，一旦项目目录结构调整（比如修改Views存放路径、组件目录更名），所有调用该组件的地方都需要手动修改路径，而官方ViewComponent基于约定的搜索路径，无需硬编码，结构变更时适应性更强。

• 无法精细化控制缓存
  官方ViewComponent支持为单个组件配置缓存策略（如通过特性或片段缓存），而单类方案下无法为不同组件单独设置缓存规则，要么全局缓存，要么完全不缓存，无法满足不同组件的缓存需求。

• IDE开发体验差
  由于dynamic类型的特性，IDE无法提供智能提示，比如在组件视图中输入Model.时，不会弹出provider、testData等字段提示，容易写错；调用Component.InvokeAsync时，匿名参数的拼写错误也无法在编译前发现，降低开发效率。

• 测试复杂度提升
  官方ViewComponent可以针对单个组件类的Invoke方法编写独立单元测试，而单类方案下，测试不同组件的逻辑需要模拟不同的baseFolder、componentName和paramData，测试用例耦合度高，难以单独验证某个组件的行为。

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