The DRY Principle in the Context of MS Dynamics 365 Backend Development

Software code is often read more than it is written. This places significant importance on the code-writing process. Maintaining code can sometimes be more challenging than developing it from scratch. Simply put, less code— especially repetitive — means fewer components to review and maintain. Numerous methods and practices for writing efficient code are detailed in the literature. This article delves into the DRY (Don't Repeat Yourself) principle, contextualized for backend development in Microsoft Dynamics 365.

Microsoft Dynamics 365 isn't just a single product. It's a suite with various versions, each having its unique features. Code can be executed within CRM (via plugins and workflows) or externally in console applications or other services. Therefore, core logic should be decoupled from where it was initiated. This facilitates running the logic in diverse environments without modifications. Consider designing shared code utilized across multiple assemblies as a Visual Studio NuGet package.

If logic is destined for multiple environments during the development phase, it's prudent to transfer shared code to an independent project. This augments code organization, with all projects accessing the shared code equally. Three primary methods to enact this rule are:

•    External Project

This relates to an independent DLL library that others can incorporate as a pre-assembled component. However, this specialized method is still widely used in many development situations. It's ideal when the assembly code is written once and remains consistent. But, as code frequently evolves, when shared code changes are required, predicting impacts on other projects becomes challenging.

•    File Link

Files from one project can be referenced in another project. While the file exists physically just once, it appears as a standard project file in multiple projects. This approach is better than its predecessor because it lets you rebuild the entire solution and run tests immediately after changes. However, there's a drawback: each file must be added individually. It can be tedious, especially in larger projects. Sometimes, the original project might fail to build due to certain incompatibilities. Even if the library DLL assembly isn't crucial, its alerts can generate undesired and often unnecessary notifications.

•    Shared Project

This unique type of project in Visual Studio primarily serves as an auxiliary and is utilized by other projects. Such a project cannot add assembly references. Instead, these references are derived from the final project. Furthermore, it cannot add files. This project is not compiled and doesn't produce its assemblies. Its code integrates into the target projects as if it were originally part of them. A clear advantage of this approach is that you don't have to add each file individually to every project.

While some guidelines suggest that interfaces should encompass all interactions between classes, this principle is often overlooked in practice. It's essential to strike a balance when implementing interfaces. If classes interact seamlessly without code repetition or outside interferences, using interfaces might be unnecessary. However, it's a clear sign to consider using interfaces if you're handling diverse object types within an array.

You should always try to form objects into groups and find commonalities in them. Common functionalities can be abstracted into a parent class. Organize objects hierarchically, emphasizing the inheritance feature of OOP. When creating such trees as parents, abstract classes show themselves best. Similar to interfaces, they allow you to define a contract using abstract methods, the implementation of which will be provided by descendants.

When applying the same logic across diverse data types, it's beneficial to consider using a method with generic parameters.

The EarlyBound generator produces a vast amount of code, reducing the need for manual checks and maintenance. Besides its benefits like readability and error reduction, it diminishes the hand-coding workload for developers. Using EarlyBound classes to craft extensions with tailored logic provides a more efficient development approach.

Traditionally, 'partial' is employed to split a sizable class into several files. Besides simplifying large classes, this method also has other advantages. Organizing these files into shared projects helps streamline their functions. This organization minimizes repetitive code and eliminates unnecessary methods and properties.

Every project is unique, demanding its approach. By integrating the tips from this article with other coding strategies, you can craft code that's not only more readable and maintainable but also efficient. Such practices improve code clarity and significantly save time and effort. Implement these strategies in your next project and see the difference for yourself.

If you need assistance, our dedicated team is always ready to help.