This is not a code which is evaluated, it’s only a declarative description of expected behavior.
Why? It’s very hard to debug this kind of code and sometimes it’s even impossible. I’m not a huge fan of this code writing approach, actually I don’t like it at all. The next important issue is fluent configuration. The resolution is to explicitly write mapping configuration for all the fields we want to map, but do I really need a heavy reflection mechanism to rewrite value from field in one object to another? Hard to debug 🔗︎ When we use tools like “show usages” it shows us only this single occurrence because there is no explicit mapping in the codebase. You can read more about problems that can be solved thanks to static analysis in my post devoted to Resharper Solution Wide Analysis Helpless code navigation 🔗︎Īnother problem is that it is not possible to find out which field from DTO maps to which field in entity (or entities). This will definitely save your code from really sophisticated bugs. You can run static analysis tool as a part of your continuous integration pipeline and treat all reported errors the same way as you treat failed unit tests. If you are in a situation where you are not burdened with errors that you have to mentally ignore, you can treat static analysis as another type of test for your system. It’s the same situation like in the story about a building with a broken window - when we have to ignore some set of errors caused by usage of given library, sooner or later we start to ignore other errors because we are not able to distinguish which one is a real problem. We’ll get feedback only when we run some kind of test during the runtime.įor me, the static analysis plays a really important role in managing the project’s code quality and when some library starts to undermine the credibility of this report I have to have a really good reason to choose that library. And again, if we rename or drop the field we silently break the system. On one side there’s AutoMapper, on the other - some kind of serializer. We experience the same situation with DTO objects. We could mark those fields with attributes (if you use Resharper static analysis) or disable this inspection completely, but that only hides the problem. So when we take advice from static analysis report and we drop those fields, we simply break the system. This issue is related to fields which are not involved in any business logic and they are simply read from user input, saved into database and read back only for raw presentation purpose (the business always wants to gather as much information as possible). There is no direct reference in the code because on one side ORM automatically maps those fields into database table columns and on the other side there is AutoMapper. The first problem is that static analysis starts to report that some fields from my entity are never used. Bear with me and I’ll explain you why this was a good decision.
#Using java reflection to disable methods trial#
Over 5 years ago I participated in a project where there was a trial of using AutoMapper but happily we drown back from this idea in time. Finally, I’ve found a provoking tweet on my timeline that definitely motivated me to materialize my reflections about AutoMapper into the form of this blog post. I’ve encountered cases when AutoMapper transforms simple thing like mapping values from object to other into a really complex problem, which results with highly complicated code only for the price of not writing mappings explicitly. Recently, I’ve came across a couple of new articles about AutoMapper and I’ve been struck when I saw how people utilize AutoMapper in their projects. The idea behind this blog post is pretty old but I haven’t had enough motivation to write this down till now.
0 kommentar(er)
