Why does SignalR use IList in its contracts and everywhere in its internal components instead of IEnumerable?

Question

I send messages to individual users depending on their roles, to ensure that I have the following code snippet:

public static void Add(Guid userId, IEnumerable<SnapshotItem> snapshot) { var hub = GlobalHost.ConnectionManager.GetHubContext<FeedbackHub>(); var items = ApplicationDbContext.Instance.InsertSnapshot(userId, Guid.NewGuid(), snapshot); foreach (var sendOperation in ConnectedUsers.Instance.EnumerateSendOperations(items)) { hub.Clients.Users(sendOperation.Groups.SelectMany(x => x.Users).Select(x => x.Id).ToList()).OnDataFeedback(sendOperation.Items); } } 

I'm not sure why I have to call .ToList() every time I need to send something, my backup store is HashSet<String> , and I want SignalR to work with this type of storage and not convert it to List every times, since it clearly consumes processing power and memory.

Since in the backstage SignalR does a simple iteration over the users or connectionIds argument, it would be wiser to use IEnumerable instead of IList , I looked at the sources of SignalR, shouldn't it be hard to achieve? Is there a special reason for using IList ?

---

Edit

Created a problem on the SignalR github page, you have to wait for one of the actual developers to clarify the situation ...

Answer 1

There is no good reason for this, as far as I can see, digging through the old source code. The irony is that IList<string> is passed to the MultipleSignalProxy class, where it is quickly displayed in a different format using a different LINQ expression, and then that is .ToList() 'd. Therefore, based on this particular use in the implementation, they really don't need anything more than an IEnumerable<string> .

Answer 2

My best answer would be that SignalR internally uses an extended IList function, for example, getting a count, or iterating over a collection, and the additional use of index-based access, which you would use for IList, but not for ICollection. The only reason to use a more robust class is because somewhere they use it or feel the need for this extra functionality. Otherwise, I would prefer best practices for using the lighter ICollection or IEnumerable class, basically the base class of this hierarchy, Enumerable-> Collection-> List.

FROM