Once I was discussing the specific technical details with my colleague, who told me to use DataTable and DataSet directly instead of any entity class. The reason for this is that there is a performance cost associated with converting an acquired dataset to an entity class.
Oh, performance. We always have this kind of irrational worry, a very mysterious look. In this case, why ORM, EF ideas, frameworks? Are the masters who created these things mystifying and over-designing? If there is a performance cost to converting a DataTable into an entity class, how big is the cost? Are the logical and productivity gains negligible?
Just as assembly language is more efficient than C, C++ and other high-level languages, most functions of modern operating systems are written in C or C++. The reason is that:
1) Performance is mainly algorithmic, and the performance gap between development languages is not decisive
2) The logic clarity, code reuse and modularity that high-level languages bring, combined with modern compilation techniques, make it possible to outperform code written by a so-called master assembler. Especially for modules of high complexity, the human brain and machine can not be compared
3) Improvement of compilation technology, recompilation of source code, can get higher performance of the finished product
4) In the development process, the first use of C and other high-level language writing, debugging, positioning success, key parts of the assembly rewrite, this idea is more conducive to success
\
Additionally, colleagues say that there is no difference between using a DataTable and an entity class. “If you add a field, don’t you change the entity class? The code that refers to the entity class has to be modified accordingly. How is this different from using a DataTable?” My colleague asked me justly.
\
I was at a loss for words and could not think of any reason to refute. I had to say weakly: “The field name has been changed, but the attributes of the entity class may not be changed.”
\
“Usually, if the name of the database field is changed, the entity class attribute should also be changed, otherwise it is easy to misunderstand.”
\
I was more speechless, helplessly said: “But the database things, directly jammed in the front, that is, the UI level, it is not good… “. To be honest, why do I want to layer, why do I want to separate the data from the UI, I just wonder. While I agree that layering is necessary, I haven’t really thought about it.
\
But then I stopped and thought about it. When I added a field, changed the name of the field, and changed the type of the field, I still need to change the entity class. But if you remove some of the fields, the benefits of the entity-like approach come out. If the page is accessed directly with the DataTable, the error will not be detected at compile time after the field is removed; But the entity class is different, the database field is deleted, the entity class should be deleted with the corresponding attribute, then all calls to the entity class attribute, compile time will report an error. If we use refactoring in VS, we can fix it automatically.
\
\