Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Gregory Alford]

Now that we have had extension for a few years, I am curious about best practices. Is it better to have one big extension or many extensions and just deal with the dependencies?

——————————
Gregory Alford
Director of Technical Resources
Tri Star Metals LLC
Aurora IL
——————————

[Andrew Good]

The answer, as is usually the case, depends on where you are starting. If you are starting from scratch, then building several small extensions makes a lot of sense since they can be managed individually. However, if you are migrating custom code from your current system, then that may be harder to achieve and a single large extension might be the way to go for now. That is, you may might need to completely re-build your customizations as extensions if you want to have several small extensions.

Another thing to think about is how you approach testing. Traditionally, this is done after the code is built. Moving in the extension world and public cloud (with monthly updates), requires a different approach to testing and development to keep your future costs in check. For any new development work you should define your tests first, then build your extension to pass the tests. These tests are then used to validate the initial development, then check it against new BC versions as they become available. The investment in building your test up front will pay dividends with every Microsoft update.

——————————
Andrew Good
President
Liberty Grove Software
Oakbrook Terrace IL
——————————
——————————————-

[Kevin Fons]

A single extension is usually better for performance as it will decrease the amount of separate table joins which will increase performance.  This is what Microsoft recommended to us for developing extensions for customers to maximize performance.

——————————
Kevin Fons
Senior Application Consultant
Innovia Consulting
Windsor WI
——————————
——————————————-

[Gregory Alford]

So at least the tables and table extensions should be in a single extension?

——————————
Gregory Alford
Director of Technical Resources
Tri Star Metals LLC
Aurora IL
——————————
——————————————-

[Kevin Fons]

Correct, but we have found it to be easiest to put everything in one extension other than extensions we may use for multiple customers or extensions related to things like the original company load or data fixes that may be run and removed at a later date.  When the customer is doing development we have in some cases created our extension and the customer has their extension to keep them separate.  Our developers may have additional more detailed insight into their best practices.

——————————
Kevin Fons
Senior Application Consultant
Innovia Consulting
Windsor WI
——————————
——————————————-

[Matt Traxinger]

I’ll tell you, this has been a topic of endless debate for us. This is the way we try to deal with it now.

Often we still approach your question simply from the developer perspective: What is easiest for us developers? In my opinion, we should ask ourselves “what aspect of quality are we trying to maximize and what constraints are we under?” I’m not saying that the developer’s opinion doesn’t matter, far from it. It’s just that they often care about significantly different things that users never actually see. You have to decide which aspects of quality you want to emphasize and for whom before you can decide how to structure your extensions.

As mentioned in another comment, more extensions equals more table joins equals slower performance, even if minor. If performance (what I’ll call efficiency or reliability) is the number one measure of the quality of the system I would keep everything in one extension. Users care a lot about this and it’s completely valid.

If you have multiple instances of NAV or BC, and re-use some of the code between them, but not all, you might care more about reusability or maintainability. Developers care about this and it’s also completely valid.

But there are trade-offs for it all. You can’t maximize for everyone.

——————————
Matt Traxinger
NAV Developer
ArcherPoint Inc.
San Antonio TX
——————————
——————————————-

[Mark Anderson]

Hey Greg

I had a similar question a while back and got some good feedback: https://www.navug.com/communities/community-home/digestviewer/viewthread?MessageKey=8e94af95-dca2-48d8-a6a1-83b5242c974b&CommunityKey=95503735-5a0b-4af1-8326-9bd7bb3b4d3d&tab=digestviewer#bm8e94af95-dca2-48d8-a6a1-83b5242c974b

Regards

mark

——————————
Mark Anderson
Director of ERP Systems
Clesen Wholesale
Evanston, IL
——————————
——————————————-

[Saurav Dhyani]

Hi All,

To Start with I think we should have multiple Extensions. Each extension for one functionality.

Reasons – 

1. The Whole idea of switching to Extension model is make apps which are reusable, Maintainable and Testable & Upgradeable.

2. The Other reason that support my thoughts is – Microsoft is also breaking one big Base app into multiple apps and as Microsoft will do that it will have impact on our Custom Extension.

3. If we have only one big Extension and it have an impact with changes in Base Microsoft App, all Custom Processes will not work as extension is not working.

4. In case of Multiple Extension then may be only one or more will require changes when base app is changed.

5. Now what about performance – Yes it was a real issue and may be a real issue in Business Central but – 

1. If you have a big custom extension which have a table extension on Customer Table.
2. Then you have 20 Extensions from ISV and all have table Extension on customer Table.

So even you spent time in thinking of reducing No of Joins that will be created you cant actually manage it. Let Microsoft Handle Performance issues.

6. The only way we can achieve – reusable, Maintainable and Testable & Upgradeable Extensions is by splitting your custom functionality into multiple Extensions.

Just my two cents!

——————————
Saurav Dhyani
Upgrade Technical Futurist
ArcherPoint Inc.
Duluth
Blog – https://saurav-nav.blogspot.com
——————————
——————————————-

[Mark Anderson]

Interesting comment Saurav

5 is my biggest concern. While table extensions help a lot with ease of upgrade they do seem to kill you in other ways (besides all the excessive joins). For example, if I want the field from the extension on all my customer facing docs (shipper, invoice, credit note, order ack), don’t I now have to make custom data sets for every report? If so, this means that instead of just customizing a layout, I have to write an extension to get the field in the data set (assuming we’re not doing anything with object designer/C/SIDE going forward

All that said, it’s encouraging to see the performance improvements that Microsoft is making

Best

Mark

——————————
Mark Anderson
Director of ERP Systems
Clesen Wholesale
Evanston, IL
——————————
——————————————-