Classes and interfaces

In this section, each class and interface of the concept will be explained in details.

Kipon.Xrm.Target<T>

Declaretive interface that states that it is implemented by a target entity of a certain type T, ex Account.

The Kipon Solid plugin extension to crmsvcutil is generating and extension of this interface for each entity included in the filter.xml, ex Entities.IAccountTarget. The Entities.IAccountTarget extends Kipon.Xrm.Target<Entities.Account> as as such it indicates that any sub-interface of Entities.IAccountTarget is representing a the entity in a pipeline where Account is the primary entity.

The SOLID princip clearly states that all dependencies should be based on abstractions, and many small interfaces it better than one big. But how does this match with the fact that crmsvcutil is generating entity classes that are not abstract, and where all attributes are defined in the class, even in cases where they are not part of the payload. The short answer is, that it does not add up. Using the strongly type entity classes directly when describing dependencies is a violation to the SOLID princip, because the stronly typed entity is not an abstraction, and it always have much more on the plat compared with what is needed in a specific context.

The Kipon Solid platform is bridging this gab by allowing you to write interfaces, that are implemented by the strongly typed entities, but also defines the exact part of the entity that is needed in a specific context. On top of that, you can now inject that interface into the plugin methods, and that way avoid creating relations based on non abstractions. To make it even better, the Kipon Solid deployment tool can analyze these interface, and registre correct filtering on your plugin, according to your interface definition.

namespace Kipon.PluginExample.Entities
{
    public partial class Account : Account.IRevenueChanged
    {
        public interface IRevenueChanged : IAccountTarget
        {
            Microsoft.Xrm.Sdk.Money Revenue { get; }
        }
    }
}

Above interface is such an example. The interface extends IAccountTarget, that extends Kipon.Xrm.Target<Entities.Account>, and as such is states that the underlying implementation is an Entity of type Account

Then it expose The Revenue property.

Finally this interface has been created as an inner interface on the generated account proxy class, and we also mark the proxy class to actually implement the interface.

The implementation details are already in place, generated by the platform

Purpose of such jummy jummy interface

• Create a facade of the entity that can be injected into plugin method, that defines the exact part of the target payload we are actually interested in.
• Describe for the kipon plugin registration tool witch fields should be added to the filter of any plugin step registration.
• Simplify any unit test, and allow you to create a mock, and inject that into any service method you wish to test.
• Stay aligned with the SOLID software princip.