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.
Related
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 6 years ago.
Improve this question
I explored c# source code reference. And I came across with interesting mention of IArithmetic<T> interface. For example, Int32, Double contain commented implementations of IArithmetic interface. I am interested by these details. As I understood, it is attempt to add "supporting" of arithmetic operations. But why are they commented? Is it bad way to add supporting generic "operators"?
It was probably scrapped due to performance reasons and not very much usability.
Primitive types supporting arithmetic operations through an interface is really not a very attractive scenario; performance would be horrible compared to simply using the value type itself due to the necessary boxing and unboxing.
What possible uses? Well, the first one to spring to mind would be the following scenario:
public Matrix<T> where T: IArithmetic<T>
or some such. Although this could be interesting, due to performance reasons, it would probably need to be solved some other way, not through interfaces; read this for very educated musing on the subject.
On top of all that, if you really need something similar to Arithmetic<T> you can always build your own with an added level of indirection.
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.
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
In C# commonly use DTO classes for data transfer. But also we can transfer data using Entity Framework generated class. But most of the time we uses DTOs to transfer data. Why DTOs needs to pass data across layers instead of using Entity Framework generated classes.
I think one reason, using dto classes does not directly bind the client to your database model, as it would if you were transferring ef classes. It allows you to make changes to your backend and in some cases keep these changes from effecting your clients. There are truly many more reasons, I think doing some research on the net will help more perhaps, there are many fantastic articles. However you will have to decide whether the use of dto classes fit into your current project. Some people say dto classes are bad and they go in depth to explain why they say so, others say the opposite and again explain why they say so. You will need to determine which is best for the task at hand. Overall I think answers for this question would be opinion dependant. Personally, I love dto classes.
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
Recently I have been asked in an Interview that: "Can you give an example of a situation where is it necessary to break the Inheritance chain?". I am not very sure if I could follow the question exactly.
Does any such situation exist when we to break the inheritance chain?
I tried google, but didn't get any clues.
A. When we get stupid questions that make no sense.
Inheritance is just a tool for managing and re-using code. Composition is a strong tool that is not part of an "inheritance-chain" so I'm guessing that's an answer they're looking for?
Another possible answer they're looking for is utilizing interfaces. As interfaces don't require an "inheritance chain". They enable you to be a little more flexible with your architecture and step away from strict inheritance "chains".
However the question implies that you have a number of objects that all inherit from one another and for some reason you "break" the chain of inheritance somewhere. There is no "set" reason why you'd do this as each implementation of OOP that addresses a problem is typically unique.
The way the interviewer phrased the question makes little to no sense. It's a bad interview question that wont result in the best answers or necessarily tell you anything about a candidate except that they don't understand your madness either ;).
EDIT: added some "better" questions.
Better questions include:
Q. What is the difference between inheritance and composition?
Q. I have the following class model (one crying out for an interface), can I improve it at all?
Q. I'm re-designing a base class and want to prevent other people from overriding this function. Can I do that?
Q. Is there a problem with calling virtual methods in class constructors, if so, what?
There's this blog post with a good explanation on why you'd want to "break the inheritance chain" (or "seal" your class).