Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm still learning much about immutability and when to use such objects and have started incorporating more Lookups into my coding for the fact that I knew them to be immutable and, hence, often better to use than Dictionaries that could be changed by clients.
That being said, I know there has been a good deal of work on introducing ReadOnlyDictionaries into .Net and I'm a bit confused where each would be more useful than the other and what specifically makes them different. I've looked online, but can't seem to find any articles explaining this difference.
For example, I saw this question and figured a Lookup would be a more ideal solution, but am confused as to why it wouldn't be.
Can anyone point me in the right direction / explain where either would be used over the other.
Thanks!!
Lookups are an easy way to group collections, where you could have one or more values for a given key. A Dictionary gives you one value for a give key, and one value only. Depending on your scenario, it may make most sense to have a Dictionary where you get back one value, or you may want to have a Lookup which would give you a collection of values.
Without a Lookup if you wanted a collection of values for a certain key you'd be stuck with something ugly like
Dictionary<int, IEnumerable<String>>
Yuk. See https://msdn.microsoft.com/en-us/library/bb460184%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396 for more on Lookups.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed last year.
This post was edited and submitted for review last year and failed to reopen the post:
Original close reason(s) were not resolved
Improve this question
C#'s List<T> class here doesn't have a Save() or Update() method. Is there any technical reason behind this?
What #MarcGravell & #Charles mentioned in Answer/Comment section, is something I'm trying to do.
If the question is clear to #MarcGravell & #Charles, I'm wondering what makes individuals like #Llama to make pretty easy statement "Question does not make sense"? Is this some kind trick to close the ticket & reduce one's workload?
To be even more specific, how to update & save the changes to specific item in the collection?
If by Save() or Update() you mean some kind of database backend, perhaps persisting the changes, then:
A list has no concept of a database
Most lists aren't involved in anything related to a database
Adding the tracking necessary would significantly increase the memory required, and decrease the performance
For a feature that isn't required basically all of the time
And which would require vastly different logic for different kinds of backend storage, which the list can't know about
If you want this kind of feature: use an ORM such as EF, LLBLGenPro, or anything else. That's what they provide. A list is basically a fancy veneer over an oversized array, and nothing else, which is fine: because most of the time, that's what you want.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Let's talk ASP.NET controllers, internal command/query handlers, etc.
Is there a de-facto/recommended type of collection to use for requests/parameters and responses/results?
Arrays
I've always liked this - in requests, the method says I want a fixed set of items. The reponse says, here's a fixed set of items.
But, ToArray() can have and overhead, and most work you do is likely to not end up producing an array.
IEnumerable<>
Seems a good way to go, though feels more 'mysterious'? And Resharper gives a billion warnings about possible multiple enumeration of them. There's a chance that enumerating might have side-effects, too.
List<>, IList<>, ICollection<>
All have Add, Remove, Clear methods. To me, means that data contracts could or should be modified. I feel that contracts should be immutable? If a method returns something with an Add method, kind of breaks the idea that the operation was pure/atomic/something like that?
IReadOnlyCollection<>, IReadOnlyList<>
Actually seem to be a pretty good answer. The List variant allows grabbing by index, not strictly necessary. Downside is the best one (collection) request extra code to wrap up, because arrays, lists and the like don't inherit IReadOnlyCollection.
Ideally I guess there would have been an IReadableCollection with read methods, and IWriteableCollection with mutation methods.
So, how do we remove the subjective factor here.
My specific question: Is there a de-facto or recommended route?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a c# method that runs certain code blocks in a certain order. I want to pass a boolean parameter : "IsRunningInReverse" that will reverse the order in which the code blocks are run?
I could just create 2 private methods that just call the statements in normal and reverse order but I'm wondering if there is a better way to accomplish this?
I was thinking about creating delegates (Action<>) and storing them in a List and then the boolean "IsRunningInReverse" would determine whether I'd run through the list in ascending or descending order but I don't know if that's the cleanest solution.
Any input would be greatly appreciated.
Thanks!
Your solution seems fine to me.
Using Actions would be an idiomatic modern C# object wrapper for delegates, you can manipulate them easily.
To put them into a list is simple and will allow for what you want (reverse order), and even more (arbitrarily reorder them)
Maybe what might be more complicated and deserves some consideration is : would you need shared data ?
It should not be too difficult to handle this, but you would need a bit more structure (design some data sharing class for instance.
If you want to go further, once you feel more at ease with your solution, is maybe learn about expression trees .
That would be a powerful tool to manipulate different operations / actions. Beware, though, there is a large learning gap, it is quite more complicated than a List of Actions. If you simple want to reverse operations, I would still deem your List<Action> idea much more clean because it is much more simple and readable. I just thought it was worth mentioning.
How I would do it:
Make your "steps" separate functions.
Make a dictionary of the tasks and the "rank".
Then just sort asc/desc depending on what you are after.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
In this post, a SO user offers an alternative to Dictionary (the HashTable implementation in C#).
What are the advantages and disadvantages of this approach?
Would performance be a disadvantage? His approach seems to iterate through all the classes to find the correct object but a HashTable would immediately find the value based on the hash function of the key, right?
A Dictionary requires unique keys, which might be an issue in some cases. Obviously the class provides encapsulation, which is always good, but the Dictionary provides more efficient lookup. It's quite possible to use both though. You use the Dictionary for fast lookup and then the value you get is a class that encapsulates all the related data for the entity, which would probably include the key as well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm not really sure, when I should consider not use reflection.
At the moment I struggling with the following scenario:
A mapping between two classes are done by reflection (with dictionary to property).
In one class we have a dictionary<string, object> and in the other class we have properties with the same name as the key of the dictionary. Then I sue reflection to get the property and set it.
You see, there are also costly castings of all the objects. And sometimes I must do a custom cast, because the types are diffrent..
The only big advantage of the reflection is the 'easy' mapping with few lines and less classes. Both Reflection and the normal property set approach is possible.
NOTE: My question is more from the perspective of design, rather of 'how to' solve the problem.
It would be appreciated if you can give me some advices.
My question is more from a perspective of design, rather of how to solve the problem
To answer your question, in general you would use Reflection to do dynamic property mappings like this. However, in practise Reflection can be heavy & slow (as you are beginning to notice). As you have probably guessed this problem is pretty common and there are already libraries out there that do all the heavy lifting for you e.g. AutoMapper.
As far as mapping a Dictionary to an object is concerned, I have never used AutoMapper for something like that therefore I couldn't comment on whether it would support it or not (my guess it it probably could, it's pretty flexible). If your Dictionary is just a bridge for your custom mapping then if you did switch to using AutoMapper you could get rid of this completely.