用于存储引用类型的 C# 引用集合
我喜欢实现一个集合（类似于 List），它可以保存我在应用程序的整个生命周期中创建的所有对象，就好像它是一个C++ 中的指针数组。这个想法是，当我的进程启动时，我可以使用中央工厂来创建所有对象，然后定期验证/无效它们的状态。基本上，我想确保我的流程仅处理有效实例，并且不会重新获取已从数据库中获取的信息。所以我的所有物品基本上都会集中在一处——我的收藏。我可以做的一件很酷的事情是，如果我已经得到了数据，就避免数据库调用从数据库中获取数据（即使我在检索后更新它，它仍然是最新的，如果其他进程没有更新它的话）这是一个不同的关注点）。如果我在过去某个时候已经初始化了 James Thomas，我不想再次调用 new Customer("James Thomas");。目前，我最终会在应用程序域中获得同一对象的多个副本 - 一些不同步，另一些同步，即使我使用 MSSQL 服务器上的 timestamp 字段处理此问题，我还是想保留我的应用程序域中的每个客户只有一份副本（如果可能，流程会更好）。
例如，我无法使用 List 或 ArrayList 等常规集合，因为我无法通过它们的真实本地引用传递参数到我使用 ref 创建它们的现有 Add() 方法，所以这不是我认为很好。那么如何实现/是否可以实现呢？一个“链表”类型的类，其中包含与 ref & 一起使用的所有方法。 out params 是我现在的想法，但它可能很快就会变得丑陋。是否有另一种方法来实现这样的集合，例如 RefList
所以底线是：如果我在整个应用程序生命周期中之前已经创建过一个对象，我不想重新创建它，除非我决定显式地重新创建它（可能它已经过时或其他原因，所以我有从数据库中再次获取它）。也许有替代方案吗？
I like to implement a collection (something like List<T>) which would hold all my objects that I have created in the entire life span of my application as if its an array of pointers in C++. The idea is that when my process starts I can use a central factory to create all objects and then periodically validate/invalidate their state. Basically I want to make sure that my process only deals with valid instances and I don't re-fetch information I already fetched from the database. So all my objects will basically be in one place - my collection. A cool thing I can do with this is avoid database calls to get data from the database if I already got it (even if I updated it after retrieval its still up-to-date if of course some other process didn't update it but that a different concern). I don't want to be calling new Customer("James Thomas"); again if I initted James Thomas already sometime in the past. Currently I will end up with multiple copies of the same object across the appdomain - some out of sync other in sync and even though I deal with this using timestamp field on the MSSQL server I'd like to keep only one copy per customer in my appdomain (if possible process would be better).
I can't use regular collections like List or ArrayList for example because I cannot pass parameters by their real local reference to the their existing Add() methods where I'm creating them using ref so that's not to good I think. So how can this be implemented/can it be implemented at all ? A 'linked list' type of class with all methods working with ref & out params is what I'm thinking now but it may get ugly pretty quickly. Is there another way to implement such collection like RefList<T>.Add(ref T obj)?
So bottom line is: I don't want re-create an object if I've already created it before during the entire application life unless I decide to re-create it explicitly (maybe its out-of-date or something so I have to fetch it again from the db). Is there alternatives maybe ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
完成您想要完成的任务的最简单方法是创建一个保存列表的包装器。该包装器将有一个接受 ref 的 add 方法。在添加中，它会查找列表中的值，并在找不到该值时创建它。或者一个缓存
但是......这个声明会让我担心。
但正如 Raymond Chen 指出的那样 错误的策略是内存泄漏的另一个名称。您所描述的是没有策略的缓存
要解决此问题，您应该考虑将其用于非Web应用程序System.Runtime.Caching 对于 4.0 或 3.5 及更早版本 企业库缓存块。如果这是一个 Web 应用程序，那么您可以使用 System.Web。缓存。或者，如果您必须自己实施，至少要制定明智的政策。
当然，所有这些都假设您的数据库缓存不足。
The easiest way to do what you're trying to accomplish is to create a wrapper that holds on to the list. This wrapper will have an add method which takes in a ref. In the add it looks up the value in the list and creates it when it can't find the value. Or a Cache
But... this statement would make me worry.
But as Raymond Chen points out that A cache with a bad policy is another name for a memory leak. What you've described is a cache with no policy
To fix this you should consider using for a non-web app either System.Runtime.Caching for 4.0 or for 3.5 and earlier the Enterprise Library Caching Block. If this is a Web App then you can use the System.Web.Caching. Or if you must roll your own at least get a sensible policy in place.
All of this of course assumes that your database's caching is insufficient.
使用 Ioc 将为您节省很多很多错误，并使您的应用程序更易于测试，并且您的模块将减少耦合。
Ioc性能相当不错。
我推荐你使用Castle项目的实现
http://stw.castleproject.org/Windsor.MainPage.ashx
也许你会需要一天的时间来学习它，但它很棒。
Using Ioc will save you many many many bugs, and make your application easier to test and your modules will be less coupled.
Ioc performance are pretty good.
I recommend you to use the implementation of Castle project
http://stw.castleproject.org/Windsor.MainPage.ashx
maybe you'll need a day to learn it, but it's great.