hi guys,
I'm programming some new functionallity that requires setup based on tables, fields, methods and classes. At first my solution used tableIds, fieldIds and classIds on the setup tables to store the required values. But then I figured out there will be a point in time the user will come with the question 'how he can copy the setup from the test to the production environment?'. And then it hit me: there's no guarantee whatsoever that a specific table.field combination in two environments will have the same tableId and fieldId. Same goes for classes: a class does not necesseraly have the same Id in different environments.
Or in other words: I'd had to disappoint the poor guy who putted all the effort in setting up and testing the solution in a pre-production environment.
Hey, but wait a minute! Maybe I don't have to disappoint him ...
What about this ID-issue they'd solved in Ax2012? Is that not helping me then?
Sure it is: each object gets an installation specific ID that will never ever change. That is: if you honour the best practices and don't intentionally ty to mess it up ... . Ok then, but will this solve my data export/import issue? Yes it does: the standard Ax data import/export functions have been improved to handle this. Check the full details on http://blogs.msdn.com/b/mfp/archive/2011/07/11/the-solution-to-the-element-id-problem.aspx.
So Ax2012 does offer great advantages over previous versions regarding object ID's. And the poor guy testing my solution can export his setup from test to production.
In the end I did decide to rewrite my solution and make it name based over ID based.
Why? Because I figured it could as well be name based: this would make the code more clear to read, understand, debug and export/import would still work fine.
And also because I do have the impression there's a shift to name based in Ax2012:
- new constructor methods 'newName' on for instance SysDictClass, sysDictTable and sysDictField
- the typical dimension[1, 2, 3] fields are gone and replaced by a new dimension framework and the corresponding bitwise-shifting-methods like fieldId2ext and fieldExt2Id are far less used throughout the application. All this makes name-based usage easier.
So should you code ID based or name based? I'm going for name based with Ax2012.
But I think there's no general rule on which of the two is better.
It's worth taking a minute or two to evaluate your situation (think about export/import, maintainability) before taking the decision.
bye
No comments:
Post a Comment