Development Choices with Microsoft Dynamics AX 2012
One of the current white papers that has been released as part of the public beta for Microsoft Dynamics AX 2012, is around your choice as a partner or customer, and how you develop and customize AX.
A direct link to that PDF white paper can be found here.: Selecting the Best Development Technology for Your Application Development Scenario in Microsoft Dynamics AX 2012
This is a really good white paper, and helps further cement the fact that with Microsoft Dynamics AX 2012, you really do have a choice in how you develop ISV offerings, and even customize AX for your unique needs as a customer.
It shows the power of Microsoft Dynamics Tools for Visual Studio, single repository, and the fact that X++ compiles down to CIL, which is the runtime language base for all .Net managed code.
I will point out the fact, that this paper does take and try to make a point that X++ is harder to learn for C# developers. This is not at all true and honestly I'm a little disappointed in the authors in making this statment.
X++ by far is a super easy sytnax to learn, and it being harder to learn over C# is not a valid arguement.
The biggest learning curve with AX that exists, and has always existed is where to put things. With AX, you can place code and business logic elements at the data, business and user layers through table methods, classes and forms.
What should be taken away, and what helps really shape where and why you should choose X++ over, say C#, is all about context. What is the context and nature of your mod, it's designed usage, and it's scale need.
If, for example you are developing a new business logic that will be used with Microsoft Dynamics AX 2012, as well as other LOB apps, and maybe some web based use, then C# WCF service that can run on-premise or in Azure is the best choice.
However, if your doing code changes to some core aspects of AX, adding a totally new module, then pure X++, or at least some X++ with hooks and events firing into C# will be your route.
From a technical aspect, it is important to understand that with Microsoft Dynamics AX 2012, there is a true interop and native calls between X++ and C#, as well as vice versa. This does open the door to all kinds of possible new ways of achieving business value add.
The bottom line, for anything to do with an ERP platform, should be governed and driven by business value add, and really not at all by technology.
If you don't have a known ROI for doing something, then you should not do it. X++, C# or anything.
So this is a great white paper, that helps highlight some good facts and context of why a pure .Net language like C# might be choosen to use over X++, still it should be tempered with real business value add, as well as the fact that both X++ and C# are tools used to create a means to an end. That end, is very Dynamic and ever growing, and the end is bottom line dollars to you as a customer, or your customers.
That's all for now, check back soon though as more to come!
"Visit the Dynamics AX Community Page today!"
A direct link to that PDF white paper can be found here.: Selecting the Best Development Technology for Your Application Development Scenario in Microsoft Dynamics AX 2012
This is a really good white paper, and helps further cement the fact that with Microsoft Dynamics AX 2012, you really do have a choice in how you develop ISV offerings, and even customize AX for your unique needs as a customer.
It shows the power of Microsoft Dynamics Tools for Visual Studio, single repository, and the fact that X++ compiles down to CIL, which is the runtime language base for all .Net managed code.
I will point out the fact, that this paper does take and try to make a point that X++ is harder to learn for C# developers. This is not at all true and honestly I'm a little disappointed in the authors in making this statment.
X++ by far is a super easy sytnax to learn, and it being harder to learn over C# is not a valid arguement.
The biggest learning curve with AX that exists, and has always existed is where to put things. With AX, you can place code and business logic elements at the data, business and user layers through table methods, classes and forms.
What should be taken away, and what helps really shape where and why you should choose X++ over, say C#, is all about context. What is the context and nature of your mod, it's designed usage, and it's scale need.
If, for example you are developing a new business logic that will be used with Microsoft Dynamics AX 2012, as well as other LOB apps, and maybe some web based use, then C# WCF service that can run on-premise or in Azure is the best choice.
However, if your doing code changes to some core aspects of AX, adding a totally new module, then pure X++, or at least some X++ with hooks and events firing into C# will be your route.
From a technical aspect, it is important to understand that with Microsoft Dynamics AX 2012, there is a true interop and native calls between X++ and C#, as well as vice versa. This does open the door to all kinds of possible new ways of achieving business value add.
The bottom line, for anything to do with an ERP platform, should be governed and driven by business value add, and really not at all by technology.
If you don't have a known ROI for doing something, then you should not do it. X++, C# or anything.
So this is a great white paper, that helps highlight some good facts and context of why a pure .Net language like C# might be choosen to use over X++, still it should be tempered with real business value add, as well as the fact that both X++ and C# are tools used to create a means to an end. That end, is very Dynamic and ever growing, and the end is bottom line dollars to you as a customer, or your customers.
That's all for now, check back soon though as more to come!
Labels: Approach, C#, design patterns, Development, Dynamics AX, Dynamics AX 2012, Microsoft, X++
posted by brandon | 6:29 PM
0 Comments:
Post a Comment
<< Home