Search icon
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Over 7,000 tech titles at $9.99 each with AI-powered learning assistants on new releases
Learning Dynamics NAV Patterns
Learning Dynamics NAV Patterns

Learning Dynamics NAV Patterns: Create solutions that are easy to maintain, are quick to upgrade, and follow proven concepts and design

By Marije Brummel
$30.99 $9.99
Book Sep 2015 214 pages 1st Edition
$30.99 $9.99
$15.99 Monthly
$30.99 $9.99
$15.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book

Learning Dynamics NAV Patterns

Introducing Dynamics NAV Patterns and Software Architecture

"Design patterns have always been the "secret source" of NAV, enabling developers to learn new areas of the application and be productive without a huge ramp up. This makes design patterns key to understanding the architecture of NAV and writing repeatable code."

Michael Nielsen, Director of NAV Development

In this book, we will journey into how to build repeatable and upgradable solutions for Microsoft Dynamics NAV. We will do this using a combination of design patterns and coding best practices. We will also cover anti-patterns, and the methodologies of handling the legacy code.

By improving the repeatability and upgradability of your software, the total cost of ownership (TCO) is reduced, which leads to better margins and better return on investment (ROI).

The examples and screenshots are based on the current version of the product, Microsoft Dynamics NAV 2015, but all of the concepts can be applied to any older version of the product too.

In this chapter, we will cover:

  • Introduction to Software Design Patterns
  • Pattern elements and hierarchy
  • The Dynamics NAV building blocks
  • The Metadata driven development

What do we mean by 'patterns'?

Wherever you look in life, you see patterns. Even life itself follows a pattern. Patterns help us in being organized by giving us structure, which makes things easier for us to understand. Without structure, we start being stressed and disorganized.

As this is true for many things in our lives, this is also true in computer programming. Applying structure in our computer programs make them easier to understand and maintain. Each profession has patterns that have proven to be successful in certain conditions, and unsuccessful in other conditions.

Software design patterns

Good old Wikipedia defines software design patterns succinctly as "A general reusable solution to a commonly occurring problem within a given context in software design." By nature, people look for ways to get organized and structured. It is not a surprise that during the 1970s and 1980s people started to look for structures in computer programming, which was a new, fast growing business.

You can read more about the software Design Patterns on Wikipedia at Software design patterns, especially in object-oriented programming (OOP), gained popularity in the 1990s when after Design Patterns: Elements of Reusable Object-Oriented Software was published by the Gang of Four, Erich Gamma, Chard Helm, Ralph Johnson, and John Vlissides. They published 23 classic software design patterns. Since then, many other patterns have been documented. Many of these were based on object-oriented programming, but people also started to document patterns outside this context.

The Procedural software design patterns

The product that we work with, Microsoft Dynamics NAV, has a programming language that people refer to as Procedural. It was invented in the 1980s and is based on Pascal, which is a very popular programming language that is still loved by many.

In this article, Paul Ford explains the history of code, procedural languages, and object oriented programming at

As with everything in life, we seek structure, hence we can apply software design patterns to Procedural languages. We just need to look carefully at all the object-oriented content that is available, and cherry-pick what applies. We can then complete this content with specifics of our language.

Procedural languages preceded the more modern object-oriented languages. One of the challenges that object-oriented programming is trying to solve is grouping things together that belong together. For this, classes are used. In this book, we will attempt to do this as well by treating tables and codeunits as a class, and then grouping functions together accordingly.

Microsoft Dynamics NAV Design Patterns

The base application that is shipped with Microsoft Dynamics NAV is full of design patterns, general reusable solutions to a commonly occurring problem within a given context in software design. Using these patterns when applicable, not only do you use solutions that have proven to work, but you also create software that people recognize as Dynamics NAV, since it will probably behave the same as the standard software.

The object-oriented patterns

The most well-known object-oriented patterns are those that are documented in the book called Elements of Reusable Object-Oriented Software, which we mentioned earlier in this chapter. Examples of these patterns are Builder, Prototype, Bridge, Singleton, Façade, and Adapter. We reuse some of these names in this book when they resemble the original pattern. Another object-oriented pattern is the Model-View-ViewModel (MVVM) pattern, which also applies to Dynamics NAV.

Non-object-oriented patterns

The base design patterns from object-oriented programming are pretty much targeted at structuring applications, running as Windows services or applications. With Microsoft Dynamics NAV, we get all of that out of the box. We don't have to think of how to get the data from the database, or how to handle concurrency.

For a better understanding of object-oriented patterns and why they don't apply to Dynamics NAV and C/AL, please read and watch the information at

The functional oriented patterns

The patterns that we use in Dynamics NAV typically are functionally oriented. They are sometimes even focused on the typical ERP problems, such as storage and formatting of address information. They still solve commonly occurring problems.

Patterns elements and hierarchy

Many books about patterns use different ways to categorise them. Patterns are closely related to the application building blocks, such as tables, fields, functions, and codeunits. Patterns will help us categorize these elements, so that we can learn different table types, and codeunit types.

Architectural patterns

When a pattern describes table definitions or a methodology to move data from one set of tables to another, we refer to it as an Architectural Pattern.

By learning Architectural patterns, we understand how the application's large building blocks are constructed. There are only a dozen of these patterns that are most commonly used. Examples are Master Data, Journals, and Rules tables.

This does not mean that any other way of designing tables and moving data is wrong by definition. It might just not be a common way of doing it, making your code harder to understand for others, and less easy to maintain.

Design patterns

Any pattern that is not related to the table definitions, or moving data in the database, is a Design Pattern. There are dozens of patterns, and in this book we'll only focus on the ones that are most commonly used, such as number series and entity state.

Structuring code

Even if you follow the patterns in this book step-by-step, your solution will be hard to maintain if you don't bring structure to your code. There are standard ways and best practices for doing this. You can find a lot of them online, mostly related to object-oriented programming, but also outside of object-oriented programming.

We can translate these best practices so that they can work with C/AL. This will help us implement best practices in Dynamics NAV, which are widely accepted in computer science.

The coding standards

The readability of your code depends in large part on how you handle variable naming and code punctuation.

For Microsoft Dynamics NAV, a wide range of documented standards are available that we will discuss in detail. Following this standard will enable other developers to read your code with ease, and seamlessly integrate your code into standard code. Remember, Microsoft Dynamics NAV offers access to the entire source of the application, so it makes sense to follow standards that are already applied throughout the standard code.

This makes it easier to clone (copy) parts of the application.


Where there are best practices, there can also be ways that are proven to be less productive. These are referred to as anti-patterns. Anti-patterns are bound to context, which means that a good pattern applied to the wrong problem can be an anti-pattern.

Code cloning

A typical example of an anti-pattern in computer programming is code cloning. This means copying and pasting similar code in your application rather than normalizing it into classes and functions. Code cloning is applied in Dynamics NAV in large proportions.

When working with C/AL, being able to copy a part of the application and making it specific to certain needs is considered powerful.

This does not yet make code cloning a good thing. We will explain good and bad examples of code cloning, and help you with a set of criteria about when cloning can be applied, and when it should be avoided.

There are many good and bad examples available in the standard application. We will discuss them in Chapter 6, Anti-patterns and Handling Legacy Code.

Legacy code

The Microsoft Dynamics NAV application code started being developed in 1980s, and grew organically.

Despite the fact that the original architect applied many patterns, we still know today from the very early days we can safely say that many parts of the application are not optimized in a way they could be if one would have the opportunity to start over.

Handling legacy code is highly important for the lifecycle of your application. Thousands of companies have been using Dynamics NAV for more than two decades, upgrading their solution every few years to the latest version.

To provide this upgrade opportunity, one should be careful when redesigning the application.

This makes it even more important to start with the correct patterns from the beginning.

Especially when dealing with limited resources, a situation that most Dynamics NAV development centers face, we want to spend as much time as possible in making new features instead of fixing issues or rewriting existing code.

We will discuss examples of how the legacy code in Microsoft Dynamics NAV was preserved, and how and when it was updated when necessary.


Microsoft Dynamics NAV has a great track record of being upgradable from one version to the next. It is possible to upgrade all the way from the earliest MS-DOS versions of the product to the latest version running on Azure in the cloud.

This requires the application architects to be very careful in making decisions. Changes made to the application may live for many years or even decades.

When upgrading to newer versions, there are two big challenges.

  • Code Upgrade: each time Microsoft ships a new version of the product, we have to see if the changes that we made to their code still function as intended. This requires not only merging code and testing of the application, but also doing a fit/gap analysis each time new functionality is added to the base application.
  • Data Upgrade: if there are changes in the way the data is stored in the table objects, we have to provide software programs that convert the data from the old structure to the new structure. This is referred to as the Upgrade Toolkit for Microsoft Dynamics NAV. You will learn about this in Chapter 6, Anti-patterns and Handling Legacy Code.

The upgrade frequency

Traditionally, customers used to upgrade the software every few years. The initial version is the active release when the implementation of a project starts. After go-live of the project, a system would typically not be touched, most often because of the upgrade cost.

Microsoft used to ship major releases of their software every few years. For customers, it was considered best practice to upgrade every other major version, depending on the return on investment.

This image illustrates this practice:

However, this best practice of upgrading has shifted dramatically with the introduction of a connected world, internet, and cloud. There is an increasing demand for being up to date with application software, and always being current.

New technologies are introduced in a higher frequency than ever before, and this has impacted the way Microsoft ships the Dynamics NAV product.

We changed to yearly release cycles and frequent rollups, which often contained new features, and new technology. Instead of upgrading every few years, there is a requirement to be (almost) always current on version, as illustrated in the next image:

This methodology is especially important when running in a Multi-Tenant environment, where individual customers no longer have a decision in their upgrading strategy.

Design patterns and upgrades

The cost of making the upgrades can be reduced by avoiding conflicts, and/or by automatically resolving conflicts. Implementing design patterns and coding best practices can help us achieve this and make upgrading easier.

Delta files

Another method to reduce the costs of shipping and merging software is using the delta files, which were introduced in 2014 by Microsoft.

Delta files are based on flat text definitions of Dynamics NAV objects, and are handled by PowerShell commandlets. The algorithms can create and apply text files on all the versions of Dynamics NAV—from 2009 and forward.

The Delta file describes, as the name implies, the delta between two objects in such a way that they can be applied to other systems quite easily. This saves time and money in merging the software.


In a cloud-first mobile-first world, repeatability becomes increasingly important. Where barely 20 years ago consultants were driving around in their cars to customers to install software and explain its use, there is an increasing trend towards click-try-buy ERP systems.

In this ecosystem, intuitive use is very important. Microsoft has invested in a user interface that makes it easier to use Dynamics NAV from a metadata perspective. However, to be really more user friendly, the metadata (UI) needs to be optimized too.

Design patterns and repeatability

Repeatable UI has been documented in Design Patterns. This makes it easy for developers to implement this in their own applications, and also makes the software work similarly across the application.

We differentiate between the classic and modern UI patterns. With multiple display targets and new devices, such as tablets being added to the product in an agile way, the UI patterns are a moving target and subject to change, version-by-version. An example of an updated pattern is statistics, wherein the classic UI totals were hidden; they are now visible on documents.

The following image illustrates an example of a modern UI on a tablet:

Lifecycle of a design pattern

Although design patterns are powerful when applied correctly, they can have negative side effects when applied in a situation where they should not be used. When choosing a design pattern to be used, it is important to see if it matches the requirements.

For example, when we need a table to store setup data, we might think of the Singleton pattern, but this only allows us to store a single set of data. If we need multiple sets, we might want to implement the Rules pattern. Both the patterns are documented in this book.

Technology changes

Design patterns can be made obsolete due to technology changes. Some languages have more built-in capabilities than others.

For example, C# has overloading, where the same function has different arguments. This is something that Dynamics NAV does not have. Therefore, we have a design pattern called the Argument table. This would be obsolete if we could overrule a function from the design time, or based on business logic.

The patterns in this book have been tested and documented for Microsoft Dynamics NAV 2015, but typically work in older versions of the product too.

Some of the design patterns in Dynamics NAV go as far back as the MS-DOS version of the product.

Old habits die hard

With technology changing, we should also question ourselves each time we design software, if we are still using the most optimal ways.

A typical example is this structure that we see a lot in the Dynamics NAV product; for example, in codeunit 81 Sales-Post (Yes/No):

OnRun(VAR Rec : Record "Table")
Rec := Table;

This code pattern started its life in the MS-DOS days, and just stayed in the application without being technically required. Developers apply it to their own objects just because it exists in many places in the standard application. We'll discuss alternative approaches in this book.

New design patterns

Sometimes, new technologies are introduced, such as charting. This then requires the new patterns that did not exist before. The following image is an example of a chart:

Other examples are patterns based on Query objects, and patterns for Activity Pages. Neither of these existed in the older versions, hence there was no requirement for Design Patterns.

Sometimes, we can reuse the existing patterns for new elements. The Activity Page uses the Singleton Pattern that we typically see for the Setup data. This adds new functional implementations for patterns, and the pattern documentation needs to be updated.

Developing SolutionsWriting software can, in many ways, be compared to building houses, or even building entire villages or cities. We need to plan ahead, but we also need to adjust to time. Things that we thought were brilliant in the 1990's are now considered old. Also with software, we need to maintain, rebuild, and rearrange as time goes by.

Software architecture in Microsoft Dynamics NAV

One thing that we need to consider when working with Microsoft Dynamics NAV is that both the metadata, and the base application deliver the base architecture for us. Unlike working in other development environments, programmers in Dynamics NAV seldom start from scratch.


Much of the program's behavior is determined by metadata, which is interpreted at runtime.

The metadata is a combination of elements, methods, and properties that gives the program its unique behavior. This also limits the possibilities that developers have using the application that enforces a certain level of simplicity.

Understanding the Metadata and base application is core for achieving success in developing your own application. The patterns and best practices in this book will help you with this.

Building blocks

To develop solutions in Microsoft Dynamics NAV, we have seven main building blocks. These blocks determine the behavior of our application together with the programming code.

The following screenshot shows the Object Designer that allows the development access to the main building blocks:

Let's go over these one by one.


The Table object allows us to define how the data is stored in the database, as well as in business logic.

The only database option for Microsoft Dynamics NAV is Microsoft SQL Server. The SQL Table definitions are automatically created, based on the Table object in Dynamics NAV.

All the business logic is handled by the Dynamics NAV runtime. The SQL Server options, such as foreign keys, triggers, or stored procedures are not used.

Unlike many other applications, Dynamics NAV is not fully normalized, given a few exceptions. Tables are bound one-to-one with the user interface. This adds a certain level of simplicity to the design that makes it easy to understand and work with. It also allows us to store historical information in a relatively simple way. For example, the customer address is copied to the posted invoice, as it was the time the invoice was printed.

This way of designing tables is crucial to understand when we deep dive into the design patterns in the later part of this book.


The user interface of Microsoft Dynamics NAV is defined using the Page objects. This is done by a combination of binding a Page object to a Table, and adding metadata.

The designer is not what you see is what you get (WYSIWYG) as we design for multiple display targets using one object definition. This makes defining the UI a highly abstract task.

The Page object inherits all the properties and methods from the underlying table. Developers have the option of adding additional properties and methods, as well as business logic that is specific to the behavior of the object.

All the logic to Create, Read, Update, and Delete (CRUD) from the database is automatically generated by the system. This makes it very easy to work with, but also enforces the relationship between a Page and Table.

We can overrule this by implementing the Model-View-ViewModel Pattern, which we will discuss later in Chapter 3, Architectural Patterns. This pattern allows us to have a UI, which is unbound to the way the data is stored in the SQL Server database.


In Microsoft Dynamics NAV, the Report objects are used for both: printing documents, and creating batch routines for data modification.

Reports are typically used to print business documents such as invoices, reminders, and balance due lists.

In addition to printing, they act as containers for batch processes, such as combined invoicing and batch posting. The reasons for using reports instead of codeunits are the possibilities of adding the UI (request page), and the built-in iteration capabilities.

This object type is outside of the scope of this book, although we occasionally mention it when describing patterns.


When writing business logic, Codeunits are the preferred place to do this. They act as containers for the code that allow us to structure our programming using known concepts such as encapsulation.

In this book, we will discuss different types of codeunits that are used as part of the design patterns, as well as best practices to structure our code.

We will discuss how, and why codeunits should be used for code in Chapter 5, Coding Best Practices.


Most business logic in Microsoft Dynamics NAV is bound to the table object, since the table behaves as a class with methods and properties.

However, when using complex iterations over many data items, it can be costly to loop over them one-by-one.

To solve this, we can define Query objects that act as predefined SQL Server queries, allowing us to join multiple tables in one read and only read the columns that we need.


To interface with Microsoft Dynamics NAV, we can use XMLPort objects. They are outside the scope of this book.


The MenuSuite object helps us to search the application. They are outside the scope of this book.

To learn more about these object types and what you can do with them, please read Programming Microsoft NAV 2015, by David Studebaker, published by Packt Publishing.


Table objects behave as classes in Microsoft Dynamics NAV, and are the base of our application. They are bound to tables in the SQL Server, and need to contain all the fields that will be used in the Page objects.

This does not mean that we cannot add references to other tables in a table object. We can reference to other tables using Flowfields and Flowfilters objects.


When we define a field in a Table, it gets added to the SQL Server table definition automatically, unless we change the FieldClass property. Flowfields and Flowfilters objects are only a part of the Dynamics NAV Metadata. They do not exist as a part of the SQL Server table definition.

If we change the property, we can join fields from other tables that we can display on all the Page objects, since they are treated as normal fields. We can also use them in C/AL code for filtering and sorting. The latter is a new option in Dynamics NAV 2015 where we can, for example, do GLAccount.SETCURRENTKEY(Balance). This used to be impossible.

The following screenshot shows the property in the Object Designer:


When using Flowfields, you can use any field in the table as a where clause. However, sometimes you might need values that are set by users at runtime. This is what Flowfilters are used for. They are defined as fields in the table, but are not added to the SQL Table definition, or available as filter or sorting criteria.

Base application

Most development projects in Microsoft Dynamics NAV don't start from scratch as empty projects. They often start from the base application that Microsoft ships. This is an ERP application that allows their users to streamline business processes.

The application originated in the 1980s just as the programming language did, and has grown organically since its first introduction.

To be an excellent Microsoft Dynamics NAV developer, understanding business processes is maybe even more crucial than understanding the language, objects, and design patterns.

Functional processes

Microsoft Dynamics NAV allows you to administer many of the functional processes. Although they all have different purposes, such as general ledger, inventory, sales, purchasing, jobs, and manufacturing, they all use the same elements that make the application recognizable for the end user.

If a user is able to post something to the general ledger, it is very likely that they can easily understand posting to the inventory. Posting sales and purchase documents have the same similarities.

This is possible by using the same structures across the application. This also makes it easier for developers to learn new parts of the application.

Many of these structures have been in the application for a long time, since they are very closely related to ERP programming. Others have been added more recently, since they are more related to intuitive UI in correlation with app-like programming.

To learn more about these functional areas and what you can do with them, please read the Microsoft NAV 2013 Application Design book by Marije Brummel, published by Packt Publishing.


In this chapter, we have learned what design patterns are, and how they started and were introduced in computer science. We learned how design patterns can be applied to Microsoft Dynamics NAV. We also learned about anti-patterns.

In the next chapter, we will build a small application in Microsoft Dynamics NAV that consists of different design patterns brought together.

Left arrow icon Right arrow icon

Key benefits

  • Design software that is maintainable outside the ecosystem of their creators
  • Ensure quality by following patterns that have been proved to work
  • Over two dozen practical Architectural and Design patterns


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.

What you will learn

Apply object-oriented practices to C/AL programming Structure your application to avoid merge conflicts Refactor legacy code and avoid anti-patterns Design decision trees to decide when to use which patterns Clone codes and their application in Dynamics NAV Make your application extensible by creating predefined hooks and facades

Product Details

Country selected

Publication date : Sep 24, 2015
Length 214 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781785284199
Vendor :
Category :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Sep 24, 2015
Length 214 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781785284199
Vendor :
Category :

Table of Contents

9 Chapters
Preface Chevron down icon Chevron up icon
1. Chapter 1: Introducing Dynamics NAV Patterns and Software Architecture Chevron down icon Chevron up icon
2. Chapter 2: Architectural Patterns Chevron down icon Chevron up icon
3. Chapter 3: Design Patterns Chevron down icon Chevron up icon
4. Chapter 4: Building an Example Application Using Patterns Chevron down icon Chevron up icon
5. Chapter 5: Coding Best Practices Chevron down icon Chevron up icon
6. Chapter 6: Anti-patterns and Handling Legacy Code Chevron down icon Chevron up icon
7. Chapter 7: Building Solutions Using Patterns Chevron down icon Chevron up icon
8. Thank you for buying Learning Dynamics NAV Patterns Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Filter icon Filter
Top Reviews

Filter reviews by

No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.