ASP.NET, CMS

Best Practices to avoid hard coding in .NET

Hard Coding

Hard coding refers to the software development practice of embedding input or configuration data directly into the source code of a program or other executable object, or fixed formatting of the data, instead of obtaining that data from external sources or generating data or formatting in the program itself with the given input.

Soft Coding

Soft coding accepts parameters or look up values in a configuration file or database that alter the flow of computer logic. A user interface may be provided to allow users to update these values. Soft coding provides limited ability for users to change the functioning of a system without a programmer. It may also be used to improve the general maintainability of code.
Below examples illustrates how we can avoid hard coding in some of the areas of an application by using various configuration files.

Below examples illustrates how we can avoid hard coding in some of the areas of an application by using various configuration files.

1) Connection Strings

Application connection strings and its related settings must not be hard coded in the code files (C# or VB) and it should always fetch from application connection/configuration files.

Ex: Database, Active Directory, Session state service, SMTP connection, Reporting DB, Analytics DB, Search connection etc…

Avoid:  Avoid hard cording connection related strings in the code files (C# or VB).

Do:  Application connection strings must read from the configuration files.

Connection strings are going to be vary for each environment, so it would be a best practice to always read the application connection strings from Configuration files. It gives us the flexibility to modify the strings directly without building/re-deploying the whole application.

2) Application Settings

Application global/module settings must be fetched from application settings files (ex: .config, .xml and. json files) which includes below settings.

Ex: Application domain names, API end points, environment settings, external/Internal redirect page links, API token/security keys, any RegEx pattern settings, CDN settings/endpoints, admin/support email addresses, File name references, authentication URLs, query parameters, any other settings which are global to application, etc…

Avoid:  Avoid hard coding global setting related strings in the code/design and markup files (C#, VB, aspx, ascx, asax and .cshtml).

Do: Always read global settings/strings from application configuration/settings files, app settings files can be modified directly without building the whole application.

3) Resource/Regional content strings

Application regional strings (multi-lingual strings) must not be hard coded in the UI layer (. cshtml, aspx, ascx and html etc…), we must develop a dynamic way to define language related strings, it could be possible by using either resource files (.resx) in asp.net or custom resource provider (database driven resource strings), admin should have the flexibility to modify the content strings any time to reflect immediately to the user without breaking the application functionality.

4) Maintain constant files/classes as required

Maintain constant classes to hold the frequently used strings like stored procedure names, DB queries, Item Id’s (CMS), Session keys,Cookie names, Query string parameters, cache keys, form keys, Uri list, user roles and cookie names etc…

Always read frequently used strings from constant classes to increase the maintainability there by avoiding hard coded strings where ever required.

5) User Action Messages

Client validation messages, Error, Confirmation, Success, warning and information related messages etc… must not be hard coded in the code files. you should maintain those messages either in configuration files or CMS/Database.

6) Use IoC and DI to resolve the object dependencies

The Dependency Inversion principle (DIP) helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules.

  1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
  2. Abstractions should not depend upon details. Details should depend upon abstractions.

 

Some of the popular DI containers for .Net is as follows:

  • Castle Windsor
  • StructureMap
  • Spring.NET
  • Autofac

 

Ex: Implementing Logger functionality using IoC and DI container.
Create a ILogger interface in in ILogger.cs to declare to the logger methods which can be used as a reference across the application.

Implement ILogger interface for FileLogger and DatabaseLogger as the concrete implementations of ILogger.

Register the concrete type (FileLogger or DatabaseLogger) as ILogger using any of DI containers in the startup class as follows.

Resolve the concrete type where ever required in the application as below.

Using above approach we can avoid tight coupling of various dependencies in the application and make it loosely coupled, hence the application maintainability becomes so easy.

7) Avoid hiding html blocks using Css/Js

Sometimes it is very often to hide the html (div/span) blocks based on the business logic using Css/Js, this could cause the search engines to crawl the hidden block content and index it in their index repository there by delivering the wrong/irrelevant search results to the user. We should need to control (disable/enable) html block content from back end, so irrelevant content will not be rendered to the client hence search engines wont index the irrelevant content.

Avoid: html block content/data visibility should not be controlled from Css/Js using “display:none” especially  when the search results are effecting with html block content data.

Do: Control the visibility of html block contents from the back end, so the irrelevant hidden content won’t be accessible to search engines.

If the product is not discontinued, then the below html snippet would show up.

8) Avoid hard coding in switch statements

Avoid hard coding switch case statements with constant values (numbers and strings)

Avoid:  Avoid hard coding case values in switch statements as below.

Do: you could use enum/reference types to represent the case values as below.

 

About The Author

Leave a Reply

*