Book Image

Learning Dynamics NAV Patterns

By : Mark Brummel, Marije Brummel
Book Image

Learning Dynamics NAV Patterns

By: Mark Brummel, Marije Brummel

Overview of this book

Microsoft Dynamics NAV is a complete ERP system, which also contains a robust set of development tools to support customization and enhancement. These include an object designer for each of the seven application object types, a business application-oriented programming language with .NET interface capability, a compiler, a debugger, and programming testing language support. Learning Dynamics NAV Patterns will guide you through the NAV way of solving problems. This book will first introduce you to patterns and the software architecture of the NAV and then help you to build an example application. Then, it walks you through the details of architectural patterns, design patterns, and implementation patterns. This book will also talk about anti-patterns and handling legacy code. Finally, it teaches you to build solutions using patterns. Proven patterns and best practices will help you create better solutions that are easy to maintain in larger teams across several locations. It will guide you through combining abstract patterns using easy-to-understand examples and will help you decide which patterns to use in which scenarios.
Table of Contents (9 chapters)
8
Thank you for buying Learning Dynamics NAV Patterns

Hooks

While the Façade has to be explicitly implemented to allow different code paths at runtime, there might also be scenarios where we are required to make changes to the code that we don't own. In these scenarios, we can implement a hook, which is nothing more than a function call that executes business logic outside of the code, but inside the transaction. The alternative to implementing hooks is raw source code modification, including creating additional variables.

The advantages of implementing hooks can be found in the area of upgradability. It does not increase maintainability, mainly because the name of the hook does not indicate what the hook does, but where it is called from. Hence we can see in the original source that there is a hook, but we need to use a Go To definition in order to see what business logic is executed.

Let's look at hooks with the help of an example:

Remember, we only implement hooks when we don't want...