1. Introducing Dynamics NAV Patterns and Software Architecture
by Mark Brummel, Christopher Studebaker, David Studebaker, David Roys, Vjekoslav Ba
Microsoft Dynamics NAV
- Microsoft Dynamics NAV
- Table of Contents
- Microsoft Dynamics NAV
- Microsoft Dynamics NAV
- Credits
- Preface
- 1. Module 1
- 1. Exploring Microsoft Dynamics NAV – An Introduction
- Understanding Microsoft Dynamics NAV
- The functional areas within Dynamics NAV
- History of Dynamics NAV
- Functional areas
- Accessing Dynamics NAV
- Summary
- 2. What's New in NAV 2016?
- Application changes
- Improvements for the application users
- Tablet client
- New application features
- Automatic payment and bank reconciliation
- Signing up for the Bank Data Conversion Service
- Reconciling payments automatically
- Reconciling bank statements automatically
- Social Listening
- Power Business Intelligence
- RapidStart services
- Schedule reports
- E-mailing documents
- Document exchange service (OCR Services)
- Exchange rates update
- Native integration with Dynamics CRM
- Universal app
- Workflow management
- Posting Preview
- Deferrals
- Development changes
- IT changes
- Summary
- Application changes
- 3. Dynamics NAV – General Considerations
- 4. The Implementation Process – From the Reseller
- 5. The Implementation Process on the Customer Side
- 6. Migrating Data
- Tools to migrate data
- RapidStart Services
- Using XMLports to migrate data
- Writing your own tools
- Converting data from the old system to Dynamics NAV's needs
- Master data
- Open entries
- Historical data
- Open documents
- Choosing a go-live date
- Summary
- Tools to migrate data
- 7. Upgrading Microsoft Dynamics NAV
- Upgrading philosophy
- Upgrades prior to Dynamics NAV 2013
- Upgrades from Dynamics NAV 2013 forward
- Upgrading process checklist
- Upgrading steps to NAV 2013
- Upgrading tools
- Summary
- 8. Development Considerations
- 9. Functional Changes on Existing Implementations
- 10. Data Analysis and Reporting
- 11. Debugging
- 12. Popular Reporting Options with Microsoft Dynamics NAV
- 1. Exploring Microsoft Dynamics NAV – An Introduction
- 2. Module 2
- 1. An Introduction to NAV 2015
- NAV 2015 – an ERP system
- Significant changes in NAV 2015
- A developer's overview of NAV 2015
- Hands-on development in NAV 2015
- Summary
- Review questions
- 2. Tables
- An overview of tables
- Enhancing our sample application
- Creating and modifying tables
- Assigning a Table Relation property
- Assigning an InitValue property
- Adding a few activity-tracking tables
- New tables for our WDTU project
- New list pages for our WDTU project
- Keys, SumIndexFields, and table relations in our examples
- Modifying a standard table
- Version list documentation
- Types of tables
- Summary
- Review questions
- 3. Data Types and Fields
- 4. Pages – The Interactive Interface
- Page design and structure overview
- Types of pages
- Page Designer
- Page components
- WDTU Page Enhancement – part 1
- Page controls
- WDTU Page Enhancement – part 2
- Page Actions
- Learning more
- Summary
- Review questions
- 5. Queries and Reports
- Queries
- Reports
- Report components – overview
- Report data flow
- Report components – detail
- Creating a Report in NAV 2015
- Summary
- Review questions
- 6. Introduction to C/SIDE and C/AL
- 7. Intermediate C/AL
- 8. Advanced NAV Development Tools
- NAV process flow
- Role Center pages
- XMLports
- Web services
- Summary
- Review questions
- 9. Successful Conclusions
- Creating new C/AL routines
- Multi-language system
- Multi-currency system
- Navigate
- Debugging in NAV 2015
- C/SIDE Test-driven development
- Other Interfaces
- NAV Application Server (NAS)
- Client Add-ins
- Customizing Help
- NAV development projects – general guidance
- Design for efficiency
- Updating and upgrading
- Supporting material
- Summary
- Review questions
- 1. An Introduction to NAV 2015
- 3. Module 3
- 1. Introducing Dynamics NAV Patterns and Software Architecture
- What do we mean by 'patterns'?
- Microsoft Dynamics NAV Design Patterns
- Patterns elements and hierarchy
- Building blocks
- Metadata
- Base application
- Summary
- 2. Architectural Patterns
- 3. Design Patterns
- 4. Building an Example Application Using Patterns
- 5. Coding Best Practices
- 6. Anti-patterns and Handling Legacy Code
- 7. Building Solutions Using Patterns
- 1. Introducing Dynamics NAV Patterns and Software Architecture
- Bibliography
- Index
"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
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.
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 https://en.wikipedia.org/wiki/Software_design_pattern. 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 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.
Note
In this article, Paul Ford explains the history of code, procedural languages, and object oriented programming at http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/#b06g24t20w15.
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.
-
No Comment