New forums for Design Patterns topics

Luc_VanDyck

We have created some new forums (fora?) where you can post topics regarding Design Patterns:

Design Patterns (General & Best Practices)
Information about Design Patterns as a concept, general design approaches and best practices.

This forum has the following subforums:

Architectural Patterns
Architectural Patterns are the larger building blocks of your applications such as tables and posting processes. They determine how the data is stored in the database and flows through the system. Examples are Documents, Master Data and Ledger Entries.

Design Patterns
They are the smaller elements that give the application the characteristics people know and are familiar with. By implementing Design Patterns you create familiarity for users across the application. Examples are Number Series, Address Integration and Blocked Entity.

Implementation Patterns
This determines the way you structure your code and objects. The patterns help you organize your application and enhance upgradability and maintainability across developers and partners. Many of the patterns are derived from Object Oriented Programming. Examples are Hooks, Façade, Encapsulation and Natural Language Programming.

These forums are moderated by Mark Brummel.

Bogdana_Botez

Awesome to have this place to discuss about NAV C/AL patterns and best practices. =D>

Miklos_Hollender

I don't really understand why design patterns became popular

1) They are carbon copies of what the standard does and if you know the standard functionality, you know them already. Instead of writing a long essay on "released entity" they could just as well write "just like status on Sales Order".

2) They are strongly add-on focused, not customization focused (too heavy weight, does not worth the effort if you think no more than 2 users will use this feature you just built)

3) Even on an add-on level, they tend towards being heavy-weight, just like the standard is. Here is an example. For the hooks pattern, using a separate object for every hook is a huge overkill. Even in an add-on, one (or one per licencing option, licence granule) suffices.

On the plus side, if you are new to this all, they help understanding the standard better.

tinoruijs

Miklos Hollender wrote:

Here is an example. For the hooks pattern, using a separate object for every hook is a huge overkill. Even in an add-on, one (or one per licencing option, licence granule) suffices.

I agree.
I'm combining all sales-related functions in codeunit "Sales Functions" for example.

Administrator

Please use the "Design Patterns" forums to discuss this, not this announcement topic.

Miklos_Hollender

Okay, Luc.