#bcalhelp #msdyn365bc What are the design guidelines and design patterns you wished you knew when you started your job as a Business Central Developer? - ThreadSky

waldo1001.bsky.social • 88 days ago

#bcalhelp #msdyn365bc

What are the design guidelines and design patterns you wished you knew when you started your job as a Business Central Developer?

Comments

rimmelzwaan.bsky.social•88 days ago

Could have used a bigger emphasis on doc -> jnl -> ledger flow, like take 3 days and really dive into the detail of CUs 80/90 and 12. Would also have benefitted GREATLY at the start of my career if someone had gotten me to read uncle Bob's book and the book about design patterns

rimmelzwaan.bsky.social•88 days ago

Also: normalization is a lost art

The 'design guidelines' you are talking about are more 'coding style guidelines' and have little to do with actual design. I think there should be a formalized class about architecture and modern design patters that is specific to BC

thedoubleh.dev•87 days ago

I would take that class. I think I have a good grasp of it, but I always like to see what other people do!

rimmelzwaan.bsky.social•87 days ago

I would also like to get a design class from the BC dev team for each new 'feature'. Shows us the objects, and explain the design considerations, the purpose of each one. Why/how of events and interfaces signatures

The 'new pricing mechanism' for instance, would LOVE to hear that one

thedoubleh.dev•87 days ago

That would be - uhm - interesting!

dnsl9r.bsky.social•88 days ago

When I started? Well the World changed a lot since then 😅

somcom.bsky.social•88 days ago

Not really a design guideline, but for BC developers it is crucial to know the application really well. The modules, application areas, data model etc. So I would learn BC before doing any dev.

armondz.bsky.social•88 days ago

almost 20 years in NAV/BC development. Still don't know it from a user perspective.

thatbcguy.bsky.social•88 days ago

- KISS
- Design from user experiences

stefanmaron.com•88 days ago

Just because a customer/consultant requests/demands some change or feature, doesn’t mean it’s set in stone.
Developers are allowed to ask why and sometimes also to say no

thatbcguy.bsky.social•87 days ago

instead of just saying no, I would also ask what happen if we don't do it. you will get people to think and talk more about it.

navfreak.bsky.social•88 days ago

- Avoid database modification operations in triggers OnAfterModifyRec, rather use OnBeforeModifyRec or another event that don't stop bulkinsert (performance)
- Don't use changecompay
- always use setloadfields/readisolation

davmac1.bsky.social•88 days ago

Never write code like codeunit 80 or 90.

navfreak.bsky.social•88 days ago

- InternalsvisibleTo in combination with internal procedures so you don't have to clutter codedunits with public functions that exist for only testing purposes.
- Group objects by functionality
- Use codecops
- Minimize database operations in tests, use temporary records
- Use /// snippet for stuff

navfreak.bsky.social•88 days ago

- Use interfaces in case operations, when applicable
- Factory pattern - because if you would like to do testing "someday" it is good if it is already there.
- tableextension methods, instead of having a random codeunit with function, add function to tableext with prefix, Customer.NBA_DoSomething

miljance.bsky.social•88 days ago

It sounds like you are documenting onboarding process :)

waldo1001.bsky.social•88 days ago

miljance.bsky.social•88 days ago

In case I am right, here is the list we came up with as sections in the onboarding documention for BC developers:
1. git
2. Docker
3. VSCode
3a. Recommended extensions
4. DevOps Boards (or Jira)
5. Time tracking
6. Postman (or REST)

Those are the "tech topics" connected to BC already.

Comments

Posting Rules

Reply