Shulou(Shulou.com)06/01 Report--

This article is to share with you about the example analysis of AutoMapper and static classes, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

In API design, the use of static classes sometimes brings some annoyance to the designer. It is often debated whether a function should be exposed as a static function or an instance method.

The main advantage of static functions is their simplicity. Callers can use static functions anywhere in the code without worrying about instance creation, management, and dependency injection. And because no new instance is created, there is no garbage collection problem, resulting in improved performance.

The above argument is true if there is no need to maintain the state. If not, the designer must ensure the thread safety of static functions, which often involves expensive locking and synchronization techniques. And even if stand-alone calls are thread-safe, callers often need to encapsulate a series of calling procedures as an atomic transaction. AutoMapper is also having trouble with this.

AutoMapper was originally designed around static functions, but its configurability has gradually improved over time. Every time a new configuration option arises, more state needs to be managed, and potential threading problems are getting worse. Therefore, in January 2020, Jimmy Bogard marked all static functions in AutoMapper 4.2 as outdated (obselete) methods, and intended to eventually remove them completely.

In the course of developing AutoMapper 4.2, I had a flash in my mind. Over the past decade, I have talked many times in lectures and podcasts about how to maintain open source code for a long time. For AutoMapper, my biggest regret is that I designed a static API at the beginning. The initial tests and prototypes of AutoMapper are called through methods such as "Mapper.CreateMap" and "Mapper.Map". I showed my code to my boss, Jeffrey Palermo, and asked him what he thought of it. He said at the time, "this looks great, Jimmy, but it seems that API should not be designed to be static," while I replied, "are you kidding? it's impossible!" .

After that, I began to realize the problem with static functions, and I still regret it. In the upcoming release, I took this opportunity to design a prototype that no longer uses static methods, which performed well, and I was ready to mark the entire static API as obsolete.

This change does cause some problems. One of the features of AutoMapper is its support for fluent API, which works with the chain of LINQ expressions. This feature requires the use of extension methods, which are often defined by static functions.

The interim solution I chose was to still provide support for LINQ, but changed its approach so that it no longer took advantage of the global state. Consumers need to pass AutoMapper configuration information to LINQ expressions, which is a bit verbose, but in some ways it provides more flexibility.

The following example is an excerpt from the static API Migration Guide:

Public class ProductsController: Controller {public ProductsController (MapperConfiguration config) {this.config = config;} private MapperConfiguration config; public ActionResult Index (int id) {var dto = dbContext.Products .Where (p = > p.Id = = id) .ProjectTo (config) .SingleOrDefault () Return View (dto);}}

But just a month later, Jimmy Bogard decided to bring these static functions back. He wrote:

One of the big problems with static API is that the user can change the configuration at any time, but I can't force the user to clean up the configuration steps. But on further reflection, I found that there was nothing wrong with the use of static API, which just required the user to complete the initialization before mapping. So I decided to allow this use in subsequent versions. The instance API is now completely complete, while the static API is actually a lightweight wrapper that allows the consumer to simply call the static Initialize method without directly calling the instance's constructor. The newly released version removes some obsolete attributes and restores the feature of using static configuration when LINQ mapping.

The above is the example analysis of AutoMapper and static classes. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.