如何在对象架构中合理处理基础设施代码与图片上传逻辑？

推荐方案：引入独立的资源加载器中间层 #

通过新增一个**资源加载器（Resource Loader）**组件，可在不破坏现有架构职责划分的前提下解决图片路径转字节的问题：

具体步骤 #

1. 定义抽象加载器接口
   先声明一个与存储实现无关的抽象接口，比如：

   public interface IResourceLoader
   {
       byte[] LoadFromPath(string path);
   }
   

   这个接口只约定路径到字节的转换能力，不绑定任何具体存储服务。

2. 实现对应存储的加载器
   根据实际的路径类型，编写具体的加载实现：

   • S3ResourceLoader：处理S3路径，调用S3 SDK读取文件字节
   • LocalFileResourceLoader：处理本地文件路径，读取本地磁盘文件
     这些加载器属于基础设施实现，但通过抽象接口与上层隔离。

3. 给连接器注入加载器依赖
   每个API连接器在初始化时，注入对应的IResourceLoader实例（或者一个能自动匹配路径类型的加载器工厂）。当连接器需要图片字节时，直接调用加载器的LoadFromPath方法，无需关心路径背后的存储类型。

   这种设计让连接器只依赖抽象接口，避免了与具体基础设施的耦合，同时满足了获取字节的需求。

4. 维持管理器的职责纯净
   管理器依旧只负责读取序列化类型、执行业务逻辑、委托连接器执行操作。它不需要感知图片加载的细节，所有资源加载逻辑都由连接器通过注入的加载器处理，不会增加管理器的复杂度。

方案优势 #

• 核心类型无需修改：继续以URL/路径建模图片，避免了全程携带大体积字节数据的性能问题。
• 连接器解耦：依赖抽象而非具体实现，符合依赖倒置原则，后续新增存储类型只需添加新的加载器即可。
• 管理器逻辑简洁：无需处理图片加载的判断和执行，保持原有职责单一。

备选方案：延迟加载代理模式 #

如果不想新增过多组件，可以对核心类型的图片路径做轻量包装：

• 将核心类型中的图片路径字段包装为LazyImage类型，内部持有路径和IResourceLoader引用。
• 当连接器需要字节时，调用LazyImage.GetBytes()方法，此时才触发实际的加载操作。
• 这种方式既保留了核心类型的简洁性，又实现了按需加载，避免了不必要的字节传输。

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