Hello, I am just starting to start building my apnetzero based management system. I need help and guidance on how to achieve the following:
I would like to keep the core of the framework with minimal changes to easily update to new versions and add isolated modules that use the framework (Rad tool, Authentication, Authorization, etc.) for my Accounting, Invoicing, HRM applications.
What is the best practice to achieve this goal?
3 Answer(s)
-
2
I'm not ANZ support - but I've found the best way is through abstraction and domain services.
For example - You could create a business logic class that does what you need. Entity relational logic, business rules, etc., and call that from the standard classes.
You may want to create more than one.
Then, in the scaffolded / default classes - you call your classes instead.
When you regen an entity or upgrade, you'll want to look at your changes - and carry over your changes.
In effect - based on advice I've gotten for a similar question - this was the advice I got.
As a simple example - in an app services createoredit method..You would copy createoredit, create, and edit to your class, and modify there, then, in the app service, inject your class and use the default methods to just wrap yours.
If you regen the entity, it will overwrite this, so you'll have to update the appservice methods to use yours instead.
It can be tedious, but I've found Checkin -> Scaffold / merge -> examine diff of all changed files and fix until it builds -> checkin to be a workable workflow.
I've actually suggested on GitHub that they leverage regions to carry over custom code.
One of my practices as well, is I use a custom region at the end of any file I know will be overwritten by the RAD tool. It makes carrying my changes over much easier, as I copy the start of that region to the end of the file to the end of the new file.
You can modify methods outright doing that if you want, then simply comment out the updated methods.
In the end, though - the advice to do a domain service has been my go to approach.
Of note - when creating domain services, where you put them matters; especially if you want to get to the DbContext. The documentation guides you to put them in Core, but I've begun to put more and more of them in the Application project.
The first project I did with ANZ, several years ago - I had a completely separate project in the solution - but I wouldn't recommend that approach now.
My only other bit of advice is not to move the files it generates. When you run the RAD tool, it'll simply recreate the file where it was, and if you've moved it, the build will fail and you'll have to unravel the issues.
One thing I really don't like about the project structure is how it dumps DTOs into one folder, instead of breaking them out for the appservice they're used by. They could all be in the same namespace, but grouping them by app service would be useful. Alas, that is unecessary.
-
0
Some other alternative that allows me automatically within the same solution to have a structure like this: Accounting\Accounts Receivable \ PaymentMethod\Dto
-
0
@marble68 good suggestions, thanks :)
