在数据库驱动的应用程序中使用享元模式
任何人都可以给我一些数据库驱动应用程序中应该使用享元模式的情况示例吗？
我怎么知道我应该在应用程序中的某个点使用享元模式？
我已经学会了蝇量级模式。但无法理解在我的数据库驱动的业务应用程序中合适的地方使用它。
Can anyone please give me any example of situation in a database-driven application where I should use Flyweight pattern?
How can I know that, I should use flyweight pattern at a point in my application?
I have learned flyweight pattern. But not able to understand an appropriate place in my database-driven business applications to use it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除了非常专业的数据库应用程序之外，Flyweight可能会被您的应用程序使用，但可能不会用于表示持久存在数据库中的实体的任何类。当需要对某个类进行多次实例化时，可以使用享元，如果每次需要时都实例化一个类，那么性能会受到影响。因此，您可以实例化数量少得多的实例，并通过仅更改每次使用的数据值来为每个所需实例重用它们。例如，在您可能必须每秒实例化数千个此类类的情况下，这将很有用，而对于保存在数据库中的实体来说，通常情况并非如此。
Except for a very specialized database application, the Flyweight might be used by your application, but probably not for any class that represents an entity which is persisted in your database. Flyweight is used when there otherwise might be a need for so many instantiations of a class that if you instantiated one every discrete time you needed it performance would suffer. So instead, you instantiate a much smaller number of them and reuse them for each required instance by just changing data values for each use. This would be useful in a situation where, for example, you might have to instantiate thousands of such classes each second, which is generally not the case for entities persisted in a database.
当任何模式自然地表明自己可以作为具体问题的解决方案时，您就应该应用它——而不是在应用程序中寻找可以应用给定模式的位置。
Flyweight 的目的是解决内存问题，因此只有在分析了应用程序并确定拥有大量相同实例后才应用它才有意义。
颜色 和 来自基类库的画笔作为示例。
由于 Flyweight 的一个非常重要的部分是共享实现是不可变的，因此数据驱动应用程序中的良好候选者将是 领域驱动设计指的是值对象 - 但只有当你有很多相同的值时它才变得相关。
You should apply any pattern when it naturally suggests itself as a solution to a concrete problem - not go looking for places in your application where you can apply a given pattern.
Flyweight's purpose is to address memory issues, so it only makes sense to apply it after you have profiled an application and determined that you have a ton of identical instances.
Colors and Brushes from the Base Class Library come to mind as examples.
Since a very important part of Flyweight is that the shared implementation is immutable, good candidates in a data-driven application would be what Domain-Driven Design refers to as Value Objects - but it only becomes relevant if you have a lot of identical values.
[不是数据库人员，所以这是我最好的猜测]
享元模式的真正好处是，如果需要，您可以重用数据；另一个例子是文字处理，理想情况下，文档中的每个“字符”都有一个对象，但这会占用太多内存，因此享元内存仅允许您存储所需的每个唯一值之一。
第二种（也许是最简单的）看待它的方法就像对象池，只是您在“每个字段”级别而不是“每个对象”级别上进行池化。
事实上，现在我想了一下，这与在 c(++) 中使用（相对较小的）内存块没有什么不同，因此存储一些原始数据，您可以通过指针操作来从中获取内容。
[查看这篇维基百科文章]。
[Not a DB guy so this is my best guess]
The real bonus to the flyweight pattern is that you can reuse data if you need to; Another example is word processing where ideally you would have an object per "character" in your document, but that wuld eat up way too much memory so the flyweight memory lets you only store one of each unique value that you need.
A second (and perhaps simplest) way to look at it is like object pooling, only you're pooling on a "per-field" level as opposed to a "per-object" level.
In fact, now that i think about it, it's not unlike using a (comparatively small) chunk of memory in c(++) so store some raw data which you do pointer manipulation to get stuff out of.
[See this wikpedia article].