MVC 中缓存图像的设计模式?

发布于 2024-10-08 13:48:56 字数 483 浏览 8 评论 0原文

我正在设计一个将在 MVC CMS 中使用的图像缓存系统。图像缓存器的主要目的是修改图像:缩放、裁剪等并将它们缓存在客户端站点中。

我创建了一个与数据库交互的图像缓存模型和映射器,以跟踪图像并了解对它们应用了哪些类型的操作(缩放、裁剪等)。

除了模型和映射器之外,我还创建了一个 ImageCacher 类,API 使用该类根据客户端站点传递的参数来管理模型和图像创建,该类创建图像并生成视图图像的链接。

一位同事认为我需要将最后一个类的功能包含在模型中,因为大部分逻辑应该放在模型中。

我非常不同意他的观点,因为我觉得模型的责任是处理有关在数据库级别缓存的图像的信息,而 ImageCacher 类的责任是创建我们将缓存的 url/图像(保持单一责任)原则)。除此之外,我认为模型不应该具有与演示相关的功能,例如创建或显示图像。

有人对此有任何见解吗?是否有一种特定的设计模式可以使任务划分清晰并且图像缓存器可重用?我应该在模型中添加所有逻辑吗?

谢谢。

I'm designing an image cache system that will be used in an MVC CMS. The main purpose of the image cacher is to modify images: scale, crop, etc and cache them in the client site.

I have created an image cache Model and Mapper that interact with the Database, to keep track of the images and know what kind of actions have been applied to them (scale, crop, etc).

In addition to the Model and Mapper I have created a ImageCacher Class that is used by the API to manage the Model and image creation based on arguments passed by the client site, this class creates the images and generates the links to the images for the View.

A coworker argued that I need to include the functionality of this last Class inside the Model, as the bulk of the logic should go in the model.

I respectfully disagree with him since I feel the model's responsibility is to deal with the information about the images cached at the database level, and the responsibility of the ImageCacher Class is to create the url/image that we will be caching (keeping the single responsibility principle). In addition to this I believe that a model should not have Presentation-related features, like creating or showing images.

Does anyone have any insight on this? is there a particular design pattern that would make this division of tasks clear and and the image cacher reusable? Should I add all the logic in the Model?

Thank you.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

陈甜 2024-10-15 13:48:56

在我看来,这需要付出太多的努力才能得到一个值得怀疑的结果。您正在构建所有逻辑,花费 CPU 和 SQL 资源来找出哪个客户端缓存了哪些图像,而客户端缓存是一种不可靠的存储方式。我不知道您的应用程序的性质,但如果多个客户端使用相同的图像文件(调整大小、裁剪等),那么首先将它们存储在客户端是不经济的。

关于。你的问题,IMO 模型是存储逻辑的地方,因为当它在模型中时更容易重用它。

IMO it's too much effort for a questionable outcome. You're building all the logic, spend CPU and SQL resources to find out which client has what images cached, while client side cache is an unreliable way to store things. I don't know the nature of your application, but if more than one client uses same image files (resized, cropped, etc) than it's counter-economic to store them client side in the first place.

Re. your question, IMO model is the place to store logic, as it's easier to reuse it when it's in model.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文