我应该如何延迟生成缩略图？
作为背景，我有一个松散地基于 Rob Conery 的 Storefront 模型等的数据层和服务层Rob，我的许多域对象都与 LazyList<> 和 LazyItem<> 链接在一起，以利用 Linq2Sql 提供的延迟执行，因为我的Lazy* 类型使用 IQueryable 而不是 这个很棒的委托方法。
所以我有一个像这样的对象图（基本上，每个 Activity 应该有一个包含许多图像的照片库 - 缩略图和全尺寸照片）：
latest3Activities[0].Gallery.Images.Inner[1].FullImage
Gallery 类型的 Images 属性为 LazyList 因此 LazyList 中的 IList 就是您看到的 Inner。 每个 PhotoGalleryImage 项都有一个 FullImage 属性和一个 Thumbnail 属性，两者都是 Image 类型。
这个想法是，完整的 rez 上传照片存储在 PhotoGalleryImage.FullImage 属性中，并且最初 Thumbnail 属性为 Null。
我想要的是：当第一次访问 Thumbnail 属性时，如果它是 Null 我希望我的服务层生成 Thumb，将其持久化DB，然后返回较小照片的 Image 实例。 我拥有从全尺寸图像创建缩略图的所有代码，所以这不是这里的问题。
我不明白的是如何捕获 Thumbnail 属性的第一次访问（在我的 IQueryable 架构上下文中），然后让服务层执行以下操作调整大小而不是存储库 (DAL)。 我强烈认为服务（业务）层应该负责此功能决策，但我不知道如何使其发挥作用。
目前，我认为从存储库中的域类到 Linq2Sql 类的映射将是识别我所指的“首次访问”的好地方，但我不知道较低层如何调用服务层并执行收缩（或者即使可以，它应该）。
也许我的设计限制我让存储库进行转换。 也许我根本不应该让服务层执行这个逻辑。 也许我的设计太可怕了，我真的不应该面对这种混乱。 我可以使用什么方法？
For background, I have a Data layer and Service layer loosely based on Rob Conery's Storefront model and like Rob's, many of my domain objects and chained with LazyList<>'s and LazyItem<>'s to make use of the deferred execution that Linq2Sql provides given that my Lazy* types utilise IQueryable<T> rather than this awesome delegate approach.
So I have an object graph like this (basically, each Activity should have a photo gallery of many images- thumbnails and full size photos):
latest3Activities[0].Gallery.Images.Inner[1].FullImage
The Gallery type has an Images property of LazyList<PhotoGalleryImage> and so the IList<PhotoGalleryImage> from that LazyList is the Inner you see. Each PhotoGalleryImage item has a FullImage property and a Thumbnail property, both of type Image.
The idea is that the full rez uploaded photo is stored in the PhotoGalleryImage.FullImage property and initially, the Thumbnail property is Null.
What I'm after is this: when the Thumbnail property is accessed for the 1st time, if it is Null I want my Service layer to generate the Thumb, persist it to the DB, then return the Image instance which is the smaller photo. I have all the code to create the thumbnail from the full size image, so that's not the question here.
What I can't figure out is how to catch the first access of the Thumbnail property (in my IQueryable<> architecture context) and then have the Service layer do the resizing and not the Repositories (DAL). I strongly feel that the Service (business) layer should be responsible for this functionality decision but I don't see how to make it work.
Currently I'm thinking the mapping from my domain classes in the repositories to the Linq2Sql classes would be a good place to identify this 'first access' I refer to, but I don't then see how a lower tier can then call up into the Service layer and perform the shrink (or even if it can, that it should).
Maybe my design constrains me to have the Repos do the conversion. Maybe I shouldn't want the Service layer to perform this logic at all. Maybe my design is just so horrid that I really shouldn't be facing this mess at all. What approach can I use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
惰性初始化的目的是推迟分配资源，因为您不知道何时或是否需要它们。
在您的情况下，这实际上没有意义：图像上传后，服务器将需要缩略图 - 用户希望立即看到新图像，对吧？ 因此，推迟缩略图的创建不会带来积极的投资回报。
The point of lazy init is to defer allocating resources since you don't know when or if you need them.
In your case, this doesn't really make sense: As soon as the image is uploaded, the server will need the thumbnail -- the user wants to see the new image immediately, right? Therefore deferring the creation of the thumbnail has no positive ROI.
几个月前，我遇到了一个非常类似的问题，涉及上传图像、缩略图生成以及生成缩略图的代码应该放在哪里的问题。 我也确实觉得这段代码属于服务层（尤其是因为图像文件和缩略图的存储被抽象到接口中并通过 IOC 容器注入，而且我不想将任何依赖项注入到我的域中）层）。
最后，我通过从 UI 控制器调用服务层来上传图像，创建了所有缩略图。 不过，在此之前我确实尝试过在域层中生成图像。 为此，我使用了一种模式，当域层需要生成图像时，它会引发一个连接到服务层的事件。 然后，服务层通过事件参数将存储接口的实例传递回域层，以便域层可以持久保存图像。 这是非常松散地基于我在Udi Dahan 的博客上遇到的关于在域模型中使用事件的一些想法作为利用服务层逻辑的一种方式。 不幸的是，我现在在 Udi 的网站上找不到参考资料，但它就在那里。 无论如何，它从来没有真正感觉正确 - 它似乎是通过另一条路线紧密耦合，这就是为什么我恢复到在图像首次通过服务层上传时创建缩略图的原因。 但是，也许在您的情况下，您可以使用域层中的事件的想法来调用服务层中的逻辑。 我确信这个想法本身有很多价值，但它不太适合我正在做的事情。
I had a very similar issue a couple of months ago with uploaded images, thumbnail generation and the question of where the code to generate the thumbnail images should go. I too really felt that this code belonged in the service layer (not least because the storage for the image files and thumbnails was abstracted out into an interface and injected via an IOC container and I didn't want to have any dependency injection into my domain layer).
In the end I created all the thumbnails at the point the image is uploaded via calls to the service layer from the UI controller. I did try generating the images in the domain layer before this though. To do this I used a pattern whereby when the domain layer needed to generate an image it raised an event which was hooked up to the service layer. The service layer then passed an instance of the storage interface back via event args to the domain layer so the domain layer could persist the image. This was very loosely based on some ideas on Udi Dahan's blog that I came across about using events in a domain model as a way of leveraging logic in the service layer. I can't find the reference on Udi's site now unfortunately but it's there somewhere. In any case it never really felt right - it seemed like tight coupling via another route, which is why I reverted to having the thumbnails created at the time the image is first uploaded via the service layer. However, perhaps in your case you could use the idea of events from the domain layer to invoke logic in the service layer. I'm sure there's a lot of value in the idea itself it just didn't quite fit what I was doing.
我假设为了显示图像，您需要图像 URI，该 URI 可以由 IThumbnailingService 传递给您，如果需要，它将生成缩略图并返回指向生成图像的有效 URI。
I assume that in order to display an image you need image URI, which can be handed to you by a
IThumbnailingService, which will generate thumbnail if required and return a valid URI which points to the generated image.