Mark Brummel - Learning Dynamics NAV Patterns

One of the many things that make Microsoft Dynamics NAV unique is that it is fully customizable and extendable. The ERP application, shipped by Microsoft as a part of NAV, is completely customizable and extendable using the traditional raw source code modification, or using the events as of Microsoft Dynamics NAV 2016. This makes the product extremely flexible and adored by the SMB market.

NAV has been built to focus on simplicity. It has been built with a strong belief that the application developer need not know all about the technical domain, like transaction isolation, advanced error recovery, database locks, memory allocations, and so on, but instead, should be able to unleash his or her domain skills. In short, write the happy path code and leave the rest to the NAVno more, no less. I still believe that these principles hold their value and lately, we can add web-services, cloud, devices, and other new terms to the list of challenges that Microsoft Dynamics NAV handles behind the scenes almost like magic.

The application that is shipped with Microsoft Dynamics NAV has been designed by keeping simplicity and extendability in mind. The simple yet powerful syntax of the the application language, the ability to copy and paste parts of the application and reuse it in a different way, has always been a part of the Microsoft Dynamics NAV DNA. Although copying and pasting, from a purely engineering perspective, could be considered bad practice, it has proven itself very productive over the years.

Over a period of time, many Patterns that are found in today's application have evolved naturally. Many of them were first used in the character-based version, upgraded to the Windows client, and then later to the current three-tier architecture. While the adherence to and use of such Patterns is purely optional for developers, multiple reasons exist to follow the recommended Patterns and guidelinesthe code will typically be easier to test and easier to upgrade, just to mention two.

By following some guidelines and principles, the sharing of application code in a large and growing community will also benefit tremendously. It might be as simple as consequent variable naming when writing code, or consistent naming of fields and tables when designing the data model.

I believe that small things like identifying recurring Patterns and assigning names to these can enhance communication, and create a common syntax between developers. It allows the community to discuss best practices, and improve and share design. This is very important, since downstream it allows the design of extensions that are easy to merge, have a lower maintenance cost, and allow easier implementation of additional changes.

Using common guidelines and best practices make it easier to work together and share code in an ecosystem that is dynamic and spans across the globe.

This is what makes Patterns unique and powerfuljust like NAV itself.

Thomas Hejlsberg

Chief Architect

Microsoft Dynamics NAV

August 2015