When I am working with MVC project I had a requirement like to clear all the errors and text entered inside a bootstrap modal. So that when I opened the modal again I could see a plain binding.

        $("#guest_form input[type='text'],input[type='password']").val('');  
        $("#guest_form input[type='text'],input[type='password']").each(function () {  
            $(this).removeClass('form-control input-validation-error');  
            $(this).addClass("form-control");  
        });  
        $(".field-validation-error").text('');  
    }); 

Initially my modal looks as follows

On submitting the modal without entering any data here my modal looks as follows

On closing the modal and opening it again I am still seeing the errors on my modal

What I need is I would like to clear all the validations and the classes which got applied using MVC validations so that it should again show me the original screen as follows

C# (Sharp) Syllabus: 

What you will learn in Pro-Developer Program:

Dependency injection

Dependency injection is a way to supply a new instance of a class with the fully-formed dependencies it requires. Most dependencies are services. Angular uses dependency injection to provide new components with the services they need.

Angular can tell which services a component needs by looking at the types of its constructor parameters. For example, the constructor of your HeroListComponent needs a HeroService:

Sample Code-

When Angular creates a component, it first asks an injector for the services that the component requires.

An injector maintains a container of service instances that it has previously created. If a requested service instance is not in the container, the injector makes one and adds it to the container before returning the service to Angular. When all requested services have been resolved and returned, Angular can call the component's constructor with those services as arguments. This is dependency injection.

The process of HeroService injection looks a bit like this:

If the injector doesn't have a HeroService, how does it know how to make one?

In brief, you must have previously registered a provider of the HeroService with the injector. A provider is something that can create or return a service, typically the service class itself.

You can register providers in modules or in components.

In general, add providers to the root module so that the same instance of a service is available everywhere.

Alternatively, register at a component level in the providers property of the @Component metadata:

  selector:    'hero-list',
  templateUrl: './hero-list.component.html',
  providers:  [ HeroService ]
})

Registering at a component level means you get a new instance of the service with each new instance of that component.

Points to remember about dependency injection:

• Dependency injection is wired into the Angular framework and used everywhere.

• The injector is the main mechanism.

  • An injector maintains a container of service instances that it created.
  • An injector can create a new service instance from a provider.

• A provider is a recipe for creating a service.

• Register providers with injectors.

Problem

You have classes that have dependencies on services or components whose concrete type is specified at design time. In this example, ClassA has dependencies on ServiceA and ServiceB. Figure 1 illustrates this.

Figure 1 
ClassA has dependencies on ServiceA and ServiceB

This situation has the following problems:

• To replace or update the dependencies, you need to change your classes' source code.
• The concrete implementations of the dependencies have to be available at compile time.
• Your classes are difficult to test in isolation because they have direct references to dependencies. This means that these dependencies cannot be replaced with stubs or mocks.
• Your classes contain repetitive code for creating, locating, and managing their dependencies.

Forces

Any of the following conditions justifies using the solution described in this pattern:

• You want to decouple your classes from their dependencies so that the dependencies can be replaced or updated with minimal or no changes to your classes' source code.
• You want to write classes that depend on classes whose concrete implementations are not known at compile time.
• You want to test your classes in isolation, without using the dependencies.
• You want to decouple your classes from being responsible for locating and managing the lifetime of dependencies.

Solution

Delegate the function of selecting a concrete implementation type for the classes' dependencies to an external component or source.

Implementation Details

The Inversion of Control pattern can be implemented in several ways. The Dependency Injection pattern and the Service Locator pattern are specialized versions of this pattern that delineate different implementations. Figure 2 illustrates the conceptual view of both patterns.

Figure2 
Conceptual view of the Service Locator and Dependency Injection patterns

For more information about these patterns, see Dependency Injection and Service Locator.

Examples

The following are example implementations of the Inversion of Control pattern:

• In the Configuration Modularity QuickStarts, the class ModuleA defined in the ModuleA project uses dependency injection to obtain a reference to the region manager service, as shown in the following code.
  C#

   

  public class ModuleA : IModule
  {
      private readonly IRegionManager _regionManager;
  
      public ModuleA(IRegionManager regionManager)
      {
          _regionManager = regionManager;
      }
  
      ...
  }
  
  

  Because the ModuleA class is instantiated by a container and an instance of the region manager service is registered with the container, the ModuleA class receives a valid instance of the region manager service when it is constructed. Note that a mock instance of the region manager service can be supplied when testing the ModuleA class by passing the mock instance in the constructor's parameter.

• The following code, extracted from the NewsModule class of the Stock Trader Reference Implementation (this class is located at StockTraderRI.Modules.News\NewsModule.cs), shows how an instance that implements the INewsController interface is obtained using the service locator pattern. The variable _container holds an instance to a container that has logic to locate a valid instance of the requested type.
  C#

   

  public void Initialize()
  {
      RegisterViewsAndServices();
      INewsController controller = _container.Resolve<INewsController>();
      controller.Run();
  }
  
  

  Note that for testing purposes, you could configure the container to return a mock instance that implements the INewsController interface instead of the real implementation. This enables you to test the NewsModule class in isolation. The following code, extracted from the NewsModuleFixture test class (located in StockTraderRI.Modules.News.Tests\NewsModuleFixture.cs), shows how the NewsModule class can be tested in isolation using a mock instance for the INewsController interface.

  C#

   

  [TestMethod]
  public void InitCallsRunOnNewsController()
  {
      MockUnityResolver container = new MockUnityResolver();
      var controller = new MockNewsController();
      container.Bag.Add(typeof(INewsController), controller);
      var newsModule = new NewsModule(container);
  
      newsModule.Initialize();
  
      Assert.IsTrue(controller.RunCalled);
  }
  
  

Liabilities

The Inversion of Control pattern has the following liabilities:

• You need to implement a mechanism that provides the dependencies that are required by the object that is being initialized.
• There is added complexity to the source code, which makes it harder to understand.