Register Custom ASP.NET MVC Routes in Sitecore

Sitecore allows custom ASP.NET MVC routes to be used on a Sitecore site.

However, improper adding of such routes may lead to different problems with using Sitecore Client, such as broken dialogues, non-functioning buttons, etc.

For example, this may be the result of defining custom routes in the Global.asax file, causing conflicts with a number of default routes defined by Sitecore and used for Sitecore Client functionality.

You can also find more information about ASP.NET Routing in the following article:
https://msdn.microsoft.com/en-us/library/cc668201.aspx

Follow the steps below to define custom ASP.NET MVC routes in a way that does not conflict with the default Sitecore routes.

Create a custom processor for the initialize pipeline and define a custom route in the Process method similar to the following:

public class RegisterCustomRoute

{

  public virtual void Process(PipelineArgs args)

  {

    RouteTable.Routes.MapRoute("CustomRoute", "some/route/{controller}/{action}/{id}");

  }

}

Add this processor to the initialize pipeline right before the Sitecore InitializeRoutes processor. You can do this with the help of the configuration patch file in the following way:

<?xml version="1.0" encoding="utf-8"?>

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">

     <sitecore>

          <pipelines>

               <initialize>

                    <processor type="MyNamespace.RegisterCustomRoute, MyAssembly" patch:before="processor[@type='Sitecore.Mvc.Pipelines.Loader.InitializeRoutes, Sitecore.Mvc']" />

               </initialize>

          </pipelines>

     </sitecore>

</configuration>

Important: ensure your custom configuration patch file is applied as the last patch to Sitecore configuration.
You can do this by placing the patch file into a subfolder of the /App_Config/Include directory. The name of the subfolder must be the last one alphabetically related to other subfolders (such as Z_CustomConfigs).

Implementation of Dependency Injection in C#.

What is Dependency Injection?

Dependency Injection (DI) is a software design pattern that allows us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.

For example, Suppose your Client class needs to use two service classes, then the best you can do is to make you Client class aware of abstraction i.e. IService interface rather than implementation i.e. Service1 and Service2 classes. In this way, you can change the implementation of the IService interface at any time (and for how many times you want) without changing the client class code.

We have the following different ways to implement DI :

Constructor Injection

• This is a widely used way to implement DI.
• Dependency Injection is done by supplying the DEPENDENCY through the class’s constructor when creating the instance of that class.
• The injected component can be used anywhere within the class.
• Recommended using when the injected dependency, you are using across the class methods.
• It addresses the most common scenario where a class requires one or more dependencies.

public interface IService {

 void Serve();

}

public class Service1 : IService {

 public void Serve() { Console.WriteLine("Service1 Called"); }

}

public class Service2 : IService {

 public void Serve() { Console.WriteLine("Service2 Called"); }

}

public class Client {

 private IService _service;

 public Client(IService service) {

 this._service = service;

 }

 public ServeMethod() { this._service.Serve(); }

}

class Program

{

 static void Main(string[] args)

 {

 //creating object

 Service1 s1 = new Service1(); 

 //passing dependency

 Client c1 = new Client(s1);

 //TO DO:

 Service2 s2 = new Service2(); 

 //passing dependency

 c1 = new Client(s2);

 //TO DO:

 }

}

The Injection happens in the constructor, bypassing the Service that implements the IService Interface. The dependencies are assembled by a "Builder" and Builder responsibilities are as follows:

• Knowing the types of each IService
• According to the request, feed the abstract IService to the Client

Property/Setter Injection

• Recommended using when a class has optional dependencies, or where the implementations may need to be swapped.
• Different logger implementations could be used in this way.
• Does not require the creation of a new object or modifying the existing one. Without changing the object state, it could work.

public interface IService {

 void Serve();

}

public class Service1 : IService {

 public void Serve() { Console.WriteLine("Service1 Called"); }

}

public class Service2 : IService {

 public void Serve() { Console.WriteLine("Service2 Called"); }

}

public class Client {

 private IService _service;

 public IService Service {

 set { this._service = value; }

 }

 public ServeMethod() { this._service.Serve(); }

}

class Program

{

 static void Main(string[] args)

 {

 //creating object

 Service1 s1 = new Service1(); 

 Client client = new Client();

 client.Service = s1; //passing dependency

 //TO DO:

 Service2 s2 = new Service2(); 

 client.Service = s2; //passing dependency

 //TO DO:

 }

}

Method Injection

• Inject the dependency into a single method and generally for the use of that method.
• It could be useful, where the whole class does not need the dependency, only one method having that dependency.
• This is the way is rarely used.

public interface IService {

 void Serve();

}

public class Service1 : IService {

 public void Serve() { Console.WriteLine("Service1 Called"); }

}

public class Service2 : IService {

 public void Serve() { Console.WriteLine("Service2 Called"); }

}

public class Client {

 private IService _service;

 public void Start(IService service) {

 service.Serve();

 }

}

class Program

{

 static void Main(string[] args)

 {

 //creating object

 Service1 s1 = new Service1(); 

 Client client = new Client(); 

 client.Start(s1); //passing dependency

 //TO DO:

 Service2 s2 = new Service2(); 

 client.Start(s2); //passing dependency

 }

}

Advantages of Dependency Injection

• Reduces class coupling
• Increases code reusability
• Improves code maintainability
• Make unit testing possible

If you want to implement DI within your ASP.NET MVC application using DI container, please does refer Dependency Injection in ASP.NET MVC5 using Unity IoC Container.

Dependency Injection in ASP.Net MVC5 using Unity Ioc Container.

Please does refer to Implementation of Dependency Injection in C#.

What is Inversion of Control?

Inversion of Control (IoC) refers to a programming style where a framework controls the program flow with the help of Dependency Injection.

The term Inversion of Control (IoC) refers to a programming style where the flow of a program has been inverted i.e. changed from the normal way. As you have done in the example of Class A and Class B. Here, dependencies are instantiated by a framework or runtime and supplied to the desired class as needed.

Step 1: Create a new ASP.NET MVC Application

Step 2: Install Unity Container

Right click on the project and click on Manage NuGet Packages and search for Unity.mvc5. Click to install Unity. mvc5 package in ASP.NET MVC application.

Note

Make sure you are connected with internet.

When it will be installed successfully, you will find the following two references add to your project and UnityConfig.cs file in App_Start Folder at a project level, as shown below:

Step 3: Register all your components with the container as in the following screenshot;

public static class UnityConfig

    {

        public static void RegisterComponents()

        {

var container = new UnityContainer();

            // register all your components with the container here

            // it is NOT necessary to register your controllers

            // e.g. container.RegisterType<ITestService, TestService>();

            container.RegisterType<IRepositry, Repositry>();

            DependencyResolver.SetResolver(new UnityDependencyResolver(container));

        }

    }

Step 4: Add a new Folder in the project of the name Repository and add the following interface and a class in this folder:

//IRepositry.cs

public interface IRepositry

    {

        string GetName();

    }

//Repositry.cs

public class Repositry: IRepositry

    {

        public string GetName()

        {

            return "Vikash Sah";

        }

    }

Step 5: After this register UnityConfig in Global.asax,

Step 6: Finally, use it in your MVC Controller,

Add Publishing Targets in Sitecore 9.1

You are usually adding new publishing targets in Sitecore because of different geographic regions or databases in different data centers where you are hosting these web databases.

For a long time, for Sitecore 8, the process for creating a new publishing target was more or less the same. You have created a new entry in ConnectionStrings.config, added new <database> entry in web.config and added new definition item in master database under “/sitecore/system/Publishing targets” node.

In Sitecore 9 process has been slightly changed. You are not changing web.config anymore but Sitecore.config and 2 additional steps are now involved for adding a new publishing target. These two more steps are adding <eventQueue> and </PropertyStoreProvider> elements in Sitecore.config.

In my example below, I will use “Pub” as the name of the publishing target database. I will use “QA” as the name of the publishing target. In my example below, I will use “Pub” as the name of the publishing target database. I will use “QA” as the name of publishing target.

Steps to add new publishing target in Sitecore 9:Steps to add new publishing target in Sitecore 9:

1. Create new target database in ConnectionStrings.config where you want content to be published:
   
   <add name="Pub" connectionString="Data Source=.\;Initial Catalog=webdbname;User ID=pubuser;Password=Password" />
2. Add new entry in master database under “/sitecore/system/Publishing targets” node.
   
   
   
   
   
   
   
3. Create a patch file under C:\inetpub\wwwroot\instancename\App_Config\Include\Project\ or any other folder based on your setup. I have named my patch config file “PublishingTargets.config” and this is it’s content (you can just copy it and change web_secondary based on name of your secondary web database specified in ConnectionStrings.config):

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
     <sitecore>
         <eventing defaultProvider="sitecore">
            <eventQueueProvider defaultEventQueue="core">
                <eventQueue name="Pub" patch:after="eventQueue[@name='web']" type="Sitecore.Data.Eventing.$(database)EventQueue, Sitecore.Kernel">
                     <param ref="dataApis/dataApi[@name='$(database)']" param1="$(name)" />
                     <param hint="" ref="PropertyStoreProvider/store[@name='$(name)']" />
                </eventQueue>
            </eventQueueProvider>
         </eventing>
         <PropertyStoreProvider defaultStore="core">
             <store name="Pub" patch:after="store[@name='web']" prefix="Pub" getValueWithoutPrefix="true" singleInstance="true" type="Sitecore.Data.Properties.$(database)PropertyStore, Sitecore.Kernel">
                  <param ref="dataApis/dataApi[@name='$(database)']" param1="$(name)" />
                  <param resolve="true" type="Sitecore.Abstractions.BaseEventManager, Sitecore.Kernel" />
                  <param resolve="true" type="Sitecore.Abstractions.BaseCacheManager, Sitecore.Kernel" />
             </store>
         </PropertyStoreProvider>
         <databases>
         <!-- Pub -->
             <database id="Pub" patch:after="database[@id='web']" singleInstance="true" type="Sitecore.Data.DefaultDatabase, Sitecore.Kernel">
                 <param desc="name">$(id)</param>
                 <icon>Images/database_web.png</icon>
                 <securityEnabled>true</securityEnabled>
                 <dataProviders hint="list:AddDataProvider">
                     <dataProvider ref="dataProviders/main" param1="$(id)">
                         <disableGroup>publishing</disableGroup>
                         <prefetch hint="raw:AddPrefetch">
                              <sc.include file="/App_Config/Prefetch/Common.config" />
                              <sc.include file="/App_Config/Prefetch/Webdb.config" />
                         </prefetch>
                     </dataProvider>
                 </dataProviders>
                <PropertyStore ref="PropertyStoreProvider/store[@name='$(id)']" />
                    <remoteEvents.EventQueue>
                        <obj ref="eventing/eventQueueProvider/eventQueue[@name='$(id)']" />
                    </remoteEvents.EventQueue>
                    <archives hint="raw:AddArchive">
                        <archive name="archive" />
                        <archive name="recyclebin" />
                    </archives>
                    <cacheSizes hint="setting">
                         <data>100MB</data>
                         <items>50MB</items>
                         <paths>2500KB</paths>
                         <itempaths>50MB</itempaths>
                         <standardValues>2500KB</standardValues>
                    </cacheSizes>
              </database>
         </databases>
     </sitecore>
</configuration>


After applying these changes, you can see now pretty new publishing target in publishing dialogue in Sitecore 9: