The Differences Between X++ (Dynamics AX) and C#
Development - November 24, 2009 11:39 pm
A twitter of a forward of an email of a blog post with links to two MSDN articles on the subject of X++ vs C# made it’s way from my computer screen onto the back of my eyeballs this morning. While the read was somewhat interesting it was more of a “here’s some nice things about one of our languages, and here’s a nice thing about another’ type of read. While highlighting the fairly minor syntactical differences between the two may be a valuable exercise to those completely unfamiliar with object oriented programming in general it’s $3 short of useless to the C# programmer ready to get his ERP on or the AX developer dipping his toes in the waters of one of the most popular programming languages on the face of the planet.
I’m going to take a different approach. The first half of this article will focus on what you can expect as an AX programmer moving to C# and the second will do just the opposite. Honestly, though, in the end this will pretty much be one huge bitch-session. But hey, at least I’m up front about it.
For the AX Developer
Speed. Yeah that was nice…
AX development compared to C# (or just about any other language) is lightning fast. You’ve had the luxury of working inside a single domain, the AX application. You’ve been able to rely on a stoic, one size fits all framework. You’ve been producing forms based on a single layout manager for an audience far more concerned with function than form. You’ve gotten used to point-and-click data binding and lazy loading for free. All of that goes down the toilet when moving to C# and the .NET framework. Yes there are extremely powerful intrinsic form controls but they don’t compare with speed and ease of AX’s controls. Yes databinding generally only takes a few calls but that path you take to get to those calls is far longer than in AX where you can build an updatable SalesTable form with filterable, sortable, lazy-loading live data in four intuitive steps and no code (create form, drag salestable to datasources, create grid, drag fields to grid, done). Not to mention the trivial things like creating a solution and project, adding references, yadda yadda. Those tasks are one step short of busywork but when you step out of AX’s safe bubble, it’s what you have to do.
Where’s My ORM?
AX handles data well. From the inline ‘AX-style’ SQL to the abstraction of almost all data handling to functions on the table object are great. The ability to hang any method you want on a table and the ability to override almost any action taken against the table are invaluable and even the best 3rd part ORMs don’t come close to the power and flexibility AX provides. Speaking of 3rd party ORMs, that’ll be a whole other ball of wax for you to tackle. Linq2Sql will kinda get you the inline SQL part but for true object mapping you’ll need a more impressive tool… and there are a lot of them. Some are big and hairy (LLBLGen, nHibernate) and some are little and cute (SubSonic). Some require complicated xml scripts, external programs, and a PhD in WTF to get running; others are point and click. Regardless, none offer the same Object-Drives-the-Schema quality of AX tables, few offer a reasonable set of event handling hooks, and none that I’ve seen are able to synchronize object and schema on the fly.
The Framework is the Forest, Can You See the Trees?
The .NET framework is massive and it does a lot of different things. On the other hand, AX is specialized and while it can do many things, it’s focus is more narrow. AX gives you one nice ‘Global’ class as a library of single purpose, simple to call functions. It’s very ‘C-like’ and that’s great when you’re just plowing through the Global class trying to remember which function replaces one string inside of another. However, if MS tried to pack all of the functionality of the .NET framework into a single class it would be a gajillion lines long and intellisense alone would drag the system to a halt. To complicate things more, the framework is divided into a heap of namespaces that are often misguiding (why is process management in the diagnostics namespace?). Luckily MSDN documentation and user groups are pretty impressive and, as mentioned above, it is one of the most popular languages on the planet. Whatever you’re doing, someone’s probably done something kind of like it before.
For the C# Developer
There’s No AX Project in Visual Studio
No there is not and it’s a darn shame. AX’s development environment is one in the same as it’s execution environment. You live, play, and work in the matrix. As you’re making changes the changes you make are taking effect immediately (in some sense of the word, especially if clustered). The only difference between the sales guy who’s still using his CD tray as a drink coaster and you, uber powerful developer, is little more than the permissions to press the little ‘AOT’ toolbar button. The AX development environment is respectable: it’s well laid out, intellisense is there, compilation is fast and easy. However, if you’re looking for the amazing plethora of tools Visual Studio provides, it’s not quite there yet.
Syntax, Compiling, and What’s With These Damn Semicolons
X++ is a dot-notation language so certain assumptions can be made and definitely hold true however there’s enough syntax fleas to make a C# itchy all over. Case sensitivity is for sissies which is a spectacular pain in the butt. There isn’t really namespacing so you can declare a variable of a certain type, give it the same name as the type, and then not know what the hell is going on later in the code: is this a static method on the type, am I access my variable, declaring a new one? AX also forces you to declare your variables at the top of a method and separate those declarations from executable code… except when it doesn’t which is nearly random. Oh, and AX isn’t really good at figuring out which objects depend or inherit from one another so if you’re changing a super-class, do a compile-forward not just a compile to make sure all of the affected classes get built.
I Don’t Know What This Is But I’m Pretty Sure It’s Not SQL
AX makes it really, really, REALLY easy to work with data, especially if the desired result is some sort of grid based on only a few tables with simple joins. Start breaking from that mold and things get weird. In general, all joins have to be linear. So, table a join b to a, join c to b is a winner. Table a join b to a join c to a has a pretty good change of returning rather unusual garbage especially of one of those joins is outer. AX also has their special brand of inline not-quite-sql. Anyone who knows sql will be able to look at any of these statements and figure out what’s going on but construct one from scratch and you’re sure to misplace at least one keyword. Not to mention both the inline sql and their ‘object datasource’ queries suffer from the same linear-joins or die rule making some data selection impossible with really bad alternatives like huge temporary tables or skirting AX’s data object model altogether and just running some real SQL through ODBC. That being said, most of what you want or need to do is extremely simple and straightforward.
So there you have it; a hopefully slightly more substantial look into the differences of C# and AX from a developer’s point of view.
No Comments »
No comments yet.
RSS feed for comments on this post. TrackBack URI
Leave a comment