New forums for Design Patterns topics

Luc_VanDyckLuc_VanDyck AartselaarPosts: 3,632Member, Moderator, Administrator
edited 2015-01-14 in Announcements
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.
No support using PM or e-mail - Please use this forum. || Search is your friend
NAV TechDays 2019: 21 & 22 November 2019, Antwerp (Belgium)

Comments

  • Bogdana_BotezBogdana_Botez Posts: 4Member, Microsoft Employee
    Awesome to have this place to discuss about NAV C/AL patterns and best practices. =D>
    Bogdana Botez
    Microsoft Dynamics NAV
  • Miklos_HollenderMiklos_Hollender Posts: 1,589Member
    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.
  • tinoruijstinoruijs Posts: 1,226Member
    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.

    Tino Ruijs
    Microsoft Dynamics NAV specialist
  • AdministratorAdministrator Posts: 2,446Member, Moderator, Administrator
    Please use the "Design Patterns" forums to discuss this, not this announcement topic.
  • Miklos_HollenderMiklos_Hollender Posts: 1,589Member
    Okay, Luc.
This discussion has been closed.