At this moment MSDN documents are coming to life. The content that I think has been very productive since its earliest days has become much more professional in recent years. (Of course I remember the time when I made MSDN documents as CD or DVD.) Not only MSDN but the technical support documents of many fronts with software products are overwhelmingly competing with each other. I recently visited Google Cloud Platform and Amazon Web Services there is. These guides are the first source, so we can learn something from the right addresses. Even as a software developer, after moving on to an average level, you need to go through documentation like these, choose a random product, read the technical documentation, make Get Start examples, and make sense of something. Let’s start with the writing, thinking I gave the necessary messages without extending the word too much.
Use configuration files as you know from one of the most popular ways of getting information to the runtime and reading the values for some settings. Over time, we are familiar with XML-based configuration files such as app.config, web.config, and we started working with .Net Core with JSON formatted content. It is quite easy to manage these JSON contents on .Net Core side. We have different methods. Furthermore, since Dependency Injection capabilities can be used, it is also possible to attach special sections to classes (even though I have an Options pattern that uses the Interface Segregation Principle and Seperation of Concerns principles, so I want to study it in the first opportunity. Let’s examine how we can manage the configuration with a few simple examples. Except mainly the default configuration files, we will work with our own custom content. We will experience our code in a console-based application, but you can also use the same techniques for other types of projects, such as the Web, Web APIs.
one | dotnet new console -o CustomConfig |
Working with our own JSON Content
For the first example we will use a file named aws.json which has the following content.
ConfigSupervisor contains the functionality of the class instances. At the beginning of our ExecuteJsonSample method we create a ConfigurationBuilder instance to handle the aws.json file. The end of the Build call We get an object instance that can be moved via the IConfigurationRoot interface. As a result, we have access to the configuration items using the indexer operator. Accessing the values of the default_region and provider fields under root is fairly easy. We use the: operator (region: name) to access the name attribute in the region.
According to this notation, we can advance using an index value when accessing an element in an array named services. With promiscuous services: 1: isPublic we have reached the value of isPublic of 1 indexed element. Of course, services can read the elements of the named directory using a loop. With the GetSection function, we simply need to get the corresponding tab from the file that the configuration manager reads. It is fairly simple to access the Key and Value values after making it movable forward with the AsEnumerable method. The runtime of the application will be as follows (find a way to read the services tab better, Burak! What is it -, 1-, 0-: D)
Associating JSON Content with Classes
Want to associate some of the tabs in the content of your JSON file? The configuration content, which is already obsolete, is associated with classes in the .NET world and can be used by managed code. It is also possible to implement this for our JSON content in .Net Core environment. First, let’s add the gameSettings.json file to my project to accommodate the following json content.
First, a ConfigurationBuilder instance is created to handle the gameSettings.json file and a configuration manager is created with the Build operation. The next part is quite enjoyable. We use the Bind method to associate the Game content to be captured with GetSection to gameConfig, which is the GameSetting object instance. According to the naming conventions in the JSON configuration, the Bind method will automatically do the correct matches for us. Then we display OS and RAM information and Name and Email values for company contacts in order to be an example. Note that unlike the previous example, all of these values can be captured via the GameConfig object, which is bound to the JSON Content after the Bind operation. The runtime results will be as follows.
Working with Memory Deployed Configuration Content
One of the interesting examples I learned from MSDN documents is that configuration information can be managed and managed as in-memory. Our new function Let’s write ExecuteInMemorySample as follows.
The AddInMemoryCollection method, which is called via the code lock point builder instance. In this method, a collection of type Dictionary <string, string> is given as a parameter. Dictionary is tailored to fit the configuration of key: value. Of course for sub-elements again: refer to the separator. In the sample collection, the Region and the Artifact are members of the same level. Artifact under Service and under it Name, MaxConcurrentCall, Type and IsPublic.
This information can be accessed via the IConfigurationRoot interface named ConfigurationManager after the Build call. Moreover, the configuration of this configuration in memory can be connected to an object for any level. When we consider the following class named Service.
GetSection (“Artifact: Service”). With the Bind (service) call, it is ensured that the Service content under Artifact is linked to the corresponding object instance. After this point, properties such as MaxConcurrentCall, Name can be accessed via managed code. The runtime of the function is as follows.
Send Configuration Parameters from the Command Line
In the in-memory solution used in the previous example, parameter values can also be sent from the command line. Although this is a nice and interesting way of using it, it can be useful in many situations. How can we do it? Let’s continue by adding the following method to the ConfigSupervisor class (the Microsoft.Extensions.Configuration.CommandLine package we initially added is required for this example)
There is also a configuration content that is kept in memory. We used the generic Dictionary collection for this. As you would guess from the command line, we can guess the contents of the args argument, which comes as a parameter to the AddCommandLine function we call through the builder. Later in the code, we display the Connection: Value and Connection: Name values. Make the contents of the main code as follows. All we do is pass the args variable to the Main function as a parameter to the ExecuteCommandLineSample call.
Of course, if we run the application without giving this parameter, we will get the default Connection: Value and Connection: Name values. In the meantime, we do not have to enter all the parameters in detail. As we reach the name, we can only enter what we want to change or assign in different orders. You can look at the following runtime results in this sense.
There are a lot of things about configuration management (I’m trying to learn MSDN ‘s pretty satisfying document). For example, the creation of a specific Entity Framework provider, the use of switch mapping techniques in command line arguments can be viewed in this context. That’s all for now. I wish you all happy days until you see each other again.
You can also access sample codes via Git.
The post On .Net Core Configuration Management appeared first on SQL.
from SQL http://ift.tt/2FrGI4b
via IFTTT
No comments: