AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 23.01.2012, 22:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,475 / 846 (79) +++++++
Регистрация: 28.10.2006
sjakalax: Name based versus Id based
Источник: http://sjakalax.blogspot.com/2012/01...-id-based.html
==============

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/...d-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


Источник: http://sjakalax.blogspot.com/2012/01...-id-based.html
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
sjakalax: DAXCONF - Role-based security (RBS) and eXtensible Data Security (XDS) Blog bot DAX Blogs 8 13.04.2011 06:50
Microsoft Dynamics CRM Team Blog: Parameterizing Fetch Based Reports Blog bot Dynamics CRM: Blogs 0 18.03.2011 20:11
Microsoft Dynamics CRM Team Blog: Fetch-Xml based Reports: Bits & Pieces Blog bot Dynamics CRM: Blogs 0 24.02.2011 21:11
Dynamic Methods Microsoft CRM: Integrations: In-line versus Queue/Batch Based Blog bot Dynamics CRM: Blogs 0 06.03.2010 10:08
Jim Wang: Get Entity/Attribute's Display Name from CRM database Blog bot Dynamics CRM: Blogs 0 28.03.2009 01:05

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 03:14.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.