数据映射器、模型和图像

发布于 08-27 21:21 字数 818 浏览 9 评论 0原文

我已经看过并阅读了大量的博客文章和论坛主题,讨论并给出了 PHP 中的数据映射器/模型实现的示例,但我还没有看到任何涉及保存文件/图像的内容。

我目前正在开发一个基于 Zend Framework 的项目,并且正在模型中进行一些图像操作(正在传递文件路径),然后我将其留给映射器以将该文件保存到适当的位置- 这是常见做法吗?

但是,您如何处理从传入的图像创建 3 个不同尺寸的图像呢?目前我有一个 setImage($path_to_tmp_name) 来检查图像类型,调整大小,然后保存回原始文件名。然后,调用 getImagePath() 返回数据映射器可以使用的当前文件路径,然后在将其保存到文件后,通过调用 setImagePath($path) 进行更改。适当的位置,例如“/content/my_images”。这对你来说听起来实用吗?

另外,您将如何处理获取该图像的 URL?您认为这是模型应该提供的东西吗?在我看来,该模型应该关心图像的存储位置或最终如何通过浏览器访问它们,因此我倾向于将其放在 ini 文件中,然后通过 URL 前缀传递给视图控制器。听起来合理吗?

我正在使用 GD 进行图像处理 - 这没有任何相关性。

更新:我一直想知道是否应该在模型中调整图像大小。该模型可能要求提供特定尺寸的“主”图像和“拇指”图像。我考虑过在模型中创建一个 getImageSpecs() 函数,该函数将返回定义所需尺寸的内容,然后一个单独的图像操作类可以执行调整大小(可能在控制器中?)然后使用 setImagePaths($images) 之类的方法将最终路径传递到模型中。

任何想法都非常感激:)

I've seen and read plenty of blog posts and forum topics talking about and giving examples of Data Mapper / Model implementations in PHP, but I've not seen any that also deal with saving files/images.

I'm currently working on a Zend Framework based project and I'm doing some image manipulation in the model (which is being passed a file path), and then I'm leaving it to the mapper to save that file to the appropriate location - is this common practise?

But then, how do you deal with creating say 3 different size images from the one passed in? At the moment I have a setImage($path_to_tmp_name) which checks the image type, resizes and then saves back to the original filename. A call to getImagePath() then returns the current file path which the data mapper can use and then change with a call to setImagePath($path) once it's saved it to the appropriate location, say "/content/my_images". Does this sound practical to you?

Also, how would you deal with getting the URL to that image? Do you see that as being something that the model should be providing? It seems to me like that model should worry about where the images are being stored or ultimately how they're accessed through a browser and so I'm inclined to put that in the ini file and just pass the URL prefix to the view through the controller. Does that sound reasonable?

I'm using GD for image manipulation - not that that's of any relevance.

UPDATE: I've been wondering if the image resizing should be done in the model at all. The model could require that it's provided a "main" image and a "thumb" image, both of certain dimensions. I've thought about creating a getImageSpecs() function in the model that would return something that defines the required sizes, then a separate image manipulation class could carry out the resizing and (perhaps in the controller?) and just pass the final paths in to the model using something like setImagePaths($images).

Any thoughts much appreciated :)

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

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

发布评论

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

评论(1

那片花海2024-09-03 21:21:29

我首先告诉您,让映射器保存文件的路径是常见的做法,因为这正是服务层(在您的情况下为映射器)应该做的事情。对于您的情况,最好的办法是为生成的每个文件创建一个路径。我建议这样做:

$path = '/path/to/root/' . substr(chunk_split(md5(<unique id for file>), 2, '/'), 0, 5);

通过执行上述操作,您的路径将类似于:/path/to/root/ab/23/。由于每个图像需要不同的尺寸,因此现在可以使用 id 名称后跟尺寸来保存每个图像。例如:

$fileName = <uniquie file id from above> . '_50_100' . $ext;

最后您需要做的就是将路径保存在数据库中。然后,您的模型可以从服务层检索路径并构建您需要的 URL。

I would 1st tell you that having a mapper save the path to the file is common practice as that is exactly what a service layer (mapper in your case) should do. The best thing in your case would be to create a path for each file generated. I would suggest doing:

$path = '/path/to/root/' . substr(chunk_split(md5(<unique id for file>), 2, '/'), 0, 5);

By doing the above your path would be something like: /path/to/root/ab/23/. Since you need different sizes for each image, you now save each image with the name of the id followed by the size. ex:

$fileName = <uniquie file id from above> . '_50_100' . $ext;

All you need to do in the end is save the path in the database. Your model can then go and retrieve the path form the service layer and build the URLs you need.

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