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 8 years ago.
Improve this question
I have a relatively small dictionary (a few hundred entries at most) that is receiving many calls (hundreds, possibly thousands per second) and many of them requires entry modification.
Performance wise, which one of this solution is generally recommended for a small list with frequent updates?
unboxing-boxing structs
define structure methods for each parameter that requires modification
use classes, that can be directly modified because they are referenced unlike structures
You should really avoid mutable value types (i.e. structures that can be modified) if at all possible, as it basically breaks the concept of a "value type" if one or more attributes of a value are not intrinsically part of the value itself (and thus can't be changed). If you need to store values that can be changed, then you should be using a class.
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 1 year ago.
Improve this question
I would like to initialize a record from a class. For example, I read in a bunch of objects from a ReST call. These objects should be immutable, so the record type would fit the bill nicely, but I want to write a bunch of code to convert them to records.
Suggestions?
I'm assuming you don't have write access to the API that creates the classes? Because, honestly, it would probably better just to rewrite that.
There are libraries available such as AutoMapper (https://github.com/AutoMapper/AutoMapper).
Beyond that, there are no casts you can use, and unless the classes are highly regular, you need to write custom conversions for each class.
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 am interested in best design pattern on below issue. Say I have 2 classes with different number of properties. I need to map instance of source class to target class' instance. Mapping source property may not be simply as just equal. There may conditional check and etc. As simplest way would be writing method and accept source class'object as parameter. Then manipulate properties and initialize target class' object. However it is not good, as there will be duplicate code and logic. Because there are will be many type of source classes. So, I will be forced writing code fach convertion. Something comes to my mimd generic methods? Thanks for your time.
Automapper worked fine for our team.
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
Let's say I have a class named Rectangle and it has some attributes like: color, width, height etc. So this class will for sure describe this object but I also want to save this object to database and later read and create object from db.
My question is should this class also have methods like "SaveRectangle", "GetOneRectangle ", "GetAllRectangles", "EditRectangle" that handles the SQL operations or is there a other good practice?
I would suggest you check out Martin Fowler's "Patterns of Enterprise Architecture".
There are several different patterns for data persistence. The pattern you describe is "Active Record". It can definitely make things easier in the short term but I have found that it often leads to issues when working with many objects.
I typically choose to use a combination of the "Data Mapper" and "Table Data Gateway" patterns that separates storage/retrieval concerns from the objects themselves. That allows me to handle both separately and, possibly, more efficiently.