I am using Silverlight with a DDD approach. I have a Person domain object that has properties such as FirstName, LastName, Address, etc. The Person needs to have an Image.
我正在使用带有DDD方法的Silverlight。我有一个Person域对象,它具有FirstName,LastName,Address等属性.Persice需要有一个Image。
What is the best way to handle this?
处理这个问题的最佳方法是什么?
I don't really want to put an Windows.Controls.Image property on the Person object because this it will be coupled to Silverlight/WPF and I might want to use this object with some other technology in the future (ASP, WinForms, the next new thing, etc).
我真的不想在Person对象上放置一个Windows.Controls.Image属性,因为它将耦合到Silverlight / WPF,我可能希望将来使用此对象与其他技术(ASP,WinForms,下一件新事物等)。
I also need to be able to save and load the image somewhere. Is it best practice to save the image to a database or to a file system? I am currently using nHibernate with Microsoft SQL Server, but I also want to be able to support nHibernate with mySql and possibly some other databases. It is also possible that I may some day want to replace nHibernate with entity framework or some other technology (I am abstracting this out using a repository).
我还需要能够在某处保存并加载图像。将图像保存到数据库或文件系统是最佳做法吗?我目前正在使用nHibernate与Microsoft SQL Server,但我也希望能够支持nHibernate与mySql以及可能的其他一些数据库。我有可能有一天想用实体框架或其他技术替换nHibernate(我正在使用存储库来抽象出来)。
Given this information, how should I handle Images for my Person?
鉴于此信息,我应该如何为我的人处理图像?
5 个解决方案
#1
Well, byte[] (or something wrapping a byte[]) is fairly portable... most anything else is going to be implementation specific.
好吧,byte [](或包含byte []的东西)是相当可移植的......大多数其他东西都是特定于实现的。
Re database vs file... for the purposes of the client apps (Silverlight, WPF, etc) I would probably expose them via a web page rather than a WCF (etc) call - i.e. some ASP.NET handler (or ASP.NET MVC route) that returns the image via an http call. Then all you actually need in the client is the path to the image (/people/images/12345 or whatever).
Re database vs file ...出于客户端应用程序的目的(Silverlight,WPF等)我可能会通过网页而不是WCF(等)调用来暴露它们 - 即一些ASP.NET处理程序(或ASP.NET) MVC路由)通过http调用返回图像。然后,客户端实际需要的只是图像的路径(/ people / images / 12345或其他)。
For storage - either is usually fine... in SQL Server 2008 you can do both at once with the file-stream type. One of the problems with storing BLOBs in the database is increasing the size, but a few (small) images won't usually hurt (unless you are using SQL Express and have a capped db size). But using the database has the advantage that a single backup includes everything.
对于存储 - 要么通常都很好......在SQL Server 2008中,您可以使用文件流类型同时执行这两项操作。将BLOB存储在数据库中的一个问题是增加了大小,但是一些(小)图像通常不会受到影响(除非您使用SQL Express并且具有上限数据库大小)。但是使用数据库的优点是单个备份包含所有内容。
Saying that, though: almost every implementation I've done like this has used files.
尽管如此:几乎我所做的每一个实现都使用了文件。
#2
Are you actually using the binary blob for anything? If not, pass around a reference to something on the filesystem. I'd be worried about pissing things off if you start carrying around byte[]'s or something.
你真的在使用二进制blob吗?如果没有,请传递对文件系统上某些内容的引用。如果你开始携带byte []或者什么东西,我会担心会把事情搞砸。
If you are WPF, everything takes a URI as an ImageSource:
如果您是WPF,则所有内容都将URI作为ImageSource:
BitmapImage pic = new BitmapImage(new Uri("YourAssembly;components/images/something.jpg"));
Keep in mind that if you go my suggested route and move this to Silverlight, you'll need a crossdomain.xml file on the domain you are dishing these things out.
请记住,如果您按照建议的路线移动并将其移至Silverlight,则您需要在域名上使用crossdomain.xml文件。
If you do need to mess with the binary blob, then keep all that as a Stream of some form and have your Person.Image class offer a way to get a StreamReader/StreamWriter like GetImageStream(). Then your database stuff can get a StreamReader and go write that stuff into the database. Without checking, my guess is just about every database out there that has binary blobs writes out using a Stream, not byte[].
如果你确实需要弄乱二进制blob,那么将所有这些保存为某种形式的Stream并让你的Person.Image类提供一种获取StreamReader / StreamWriter的方法,如GetImageStream()。然后你的数据库东西可以获得一个StreamReader并将这些东西写入数据库。如果不进行检查,我的猜测就是每个数据库都有二进制blob使用Stream写入,而不是byte []。
...Just some thoughts. Dont forget BitmapImage lets you tap into its Stream too, but you'll have to look that up in the docs :-) Hope that helps.
......只是一些想法。不要忘记BitmapImage也允许你点击它的流,但你必须在文档中查找:-)希望有所帮助。
#3
I'd go with the file system for several reasons:
我会使用文件系统,原因如下:
- You don't have to store the image type in a separate field (BMP? JPEG? PNG?)
- You have the option of using a lightweight, finely-tuned server to serve your images (or, several, if your scaling needs demand it)
- You don't need to mess with byte[]s in your code - just use a string
- You'll have fewer problems if you decide to change database - you might even be able to get by with INSERT scripts for your migrations
您不必将图像类型存储在单独的字段中(BMP?JPEG?PNG?)
您可以选择使用轻量级,经过精心调整的服务器来为您的图像提供服务(或者,如果您的扩展需求需要,可以选择多个服务器)
您不需要在代码中混乱使用byte [] - 只需使用字符串即可
如果您决定更改数据库,则问题会更少 - 您甚至可以使用INSERT脚本来进行迁移
#4
Best practise is to encapsulate difficult decisions. Define your own Image class and hide the implementation.
最佳做法是封装困难的决策。定义自己的Image类并隐藏实现。
Assuming you're not writing an image editing application, the domain part of your Image class is going to be thin. Presentation and storage are not in your domain image class, they are in adapters.
假设您没有编写图像编辑应用程序,Image类的域部分将变得很薄。演示文稿和存储不在您的域映像类中,它们位于适配器中。
#5
Hm, there is System.Drawing.Image which is pretty much technology-independent. It represents exactly what you want (imo): Something that can be loaded/saved from/to some stream in some well-known image format and that can be displayed on the screen (either in WinForms or WPF).
嗯,有System.Drawing.Image,它几乎与技术无关。它完全代表你想要的东西(imo):可以用一些众所周知的图像格式加载/保存到某些流中并可以在屏幕上显示的东西(在WinForms或WPF中)。
#1
Well, byte[] (or something wrapping a byte[]) is fairly portable... most anything else is going to be implementation specific.
好吧,byte [](或包含byte []的东西)是相当可移植的......大多数其他东西都是特定于实现的。
Re database vs file... for the purposes of the client apps (Silverlight, WPF, etc) I would probably expose them via a web page rather than a WCF (etc) call - i.e. some ASP.NET handler (or ASP.NET MVC route) that returns the image via an http call. Then all you actually need in the client is the path to the image (/people/images/12345 or whatever).
Re database vs file ...出于客户端应用程序的目的(Silverlight,WPF等)我可能会通过网页而不是WCF(等)调用来暴露它们 - 即一些ASP.NET处理程序(或ASP.NET) MVC路由)通过http调用返回图像。然后,客户端实际需要的只是图像的路径(/ people / images / 12345或其他)。
For storage - either is usually fine... in SQL Server 2008 you can do both at once with the file-stream type. One of the problems with storing BLOBs in the database is increasing the size, but a few (small) images won't usually hurt (unless you are using SQL Express and have a capped db size). But using the database has the advantage that a single backup includes everything.
对于存储 - 要么通常都很好......在SQL Server 2008中,您可以使用文件流类型同时执行这两项操作。将BLOB存储在数据库中的一个问题是增加了大小,但是一些(小)图像通常不会受到影响(除非您使用SQL Express并且具有上限数据库大小)。但是使用数据库的优点是单个备份包含所有内容。
Saying that, though: almost every implementation I've done like this has used files.
尽管如此:几乎我所做的每一个实现都使用了文件。
#2
Are you actually using the binary blob for anything? If not, pass around a reference to something on the filesystem. I'd be worried about pissing things off if you start carrying around byte[]'s or something.
你真的在使用二进制blob吗?如果没有,请传递对文件系统上某些内容的引用。如果你开始携带byte []或者什么东西,我会担心会把事情搞砸。
If you are WPF, everything takes a URI as an ImageSource:
如果您是WPF,则所有内容都将URI作为ImageSource:
BitmapImage pic = new BitmapImage(new Uri("YourAssembly;components/images/something.jpg"));
Keep in mind that if you go my suggested route and move this to Silverlight, you'll need a crossdomain.xml file on the domain you are dishing these things out.
请记住,如果您按照建议的路线移动并将其移至Silverlight,则您需要在域名上使用crossdomain.xml文件。
If you do need to mess with the binary blob, then keep all that as a Stream of some form and have your Person.Image class offer a way to get a StreamReader/StreamWriter like GetImageStream(). Then your database stuff can get a StreamReader and go write that stuff into the database. Without checking, my guess is just about every database out there that has binary blobs writes out using a Stream, not byte[].
如果你确实需要弄乱二进制blob,那么将所有这些保存为某种形式的Stream并让你的Person.Image类提供一种获取StreamReader / StreamWriter的方法,如GetImageStream()。然后你的数据库东西可以获得一个StreamReader并将这些东西写入数据库。如果不进行检查,我的猜测就是每个数据库都有二进制blob使用Stream写入,而不是byte []。
...Just some thoughts. Dont forget BitmapImage lets you tap into its Stream too, but you'll have to look that up in the docs :-) Hope that helps.
......只是一些想法。不要忘记BitmapImage也允许你点击它的流,但你必须在文档中查找:-)希望有所帮助。
#3
I'd go with the file system for several reasons:
我会使用文件系统,原因如下:
- You don't have to store the image type in a separate field (BMP? JPEG? PNG?)
- You have the option of using a lightweight, finely-tuned server to serve your images (or, several, if your scaling needs demand it)
- You don't need to mess with byte[]s in your code - just use a string
- You'll have fewer problems if you decide to change database - you might even be able to get by with INSERT scripts for your migrations
您不必将图像类型存储在单独的字段中(BMP?JPEG?PNG?)
您可以选择使用轻量级,经过精心调整的服务器来为您的图像提供服务(或者,如果您的扩展需求需要,可以选择多个服务器)
您不需要在代码中混乱使用byte [] - 只需使用字符串即可
如果您决定更改数据库,则问题会更少 - 您甚至可以使用INSERT脚本来进行迁移
#4
Best practise is to encapsulate difficult decisions. Define your own Image class and hide the implementation.
最佳做法是封装困难的决策。定义自己的Image类并隐藏实现。
Assuming you're not writing an image editing application, the domain part of your Image class is going to be thin. Presentation and storage are not in your domain image class, they are in adapters.
假设您没有编写图像编辑应用程序,Image类的域部分将变得很薄。演示文稿和存储不在您的域映像类中,它们位于适配器中。
#5
Hm, there is System.Drawing.Image which is pretty much technology-independent. It represents exactly what you want (imo): Something that can be loaded/saved from/to some stream in some well-known image format and that can be displayed on the screen (either in WinForms or WPF).
嗯,有System.Drawing.Image,它几乎与技术无关。它完全代表你想要的东西(imo):可以用一些众所周知的图像格式加载/保存到某些流中并可以在屏幕上显示的东西(在WinForms或WPF中)。