Search This Blog

19 June 2011

The BC.Net in Dynamics Ax 2012

I've never been a fan of using the BC.Net in client applications. It's true that this is a very easy to use interface, but in most use-cases the Ax-client or the AIF are a better choice. The BC.Net is in fact a regular Ax-client without UI (user interface) and this means that it requires such an installation with the application that has been written - with all the constraints of the Ax-client plus some BC.Net specific ones:
  1. Local BC.Net installation (not easily maintainable when deploying on a larger scale)
  2. Dynamics Ax 2009 doesn't support side-by-side installations of clients (inflexible architecture)
  3. RPC-protocol (constraint for the infrastructure: Firewall)
  4. No multi-threading (lousy performance). Using multi-threading with the BC.Net results always in exceptions.
  5. No session-management. Only one session at a time. (no scalability) A very complex session-management needs to be written.
  6. No contract for the method and its signature (difficultly maintainable when application changes over the time) as it is available with the AIF (service+Xsd or Wsdl with AIF-WebServices)
  7. BC.Net requires the Enterprise Portal license when hosted by the IIS (this constraint is hardcoded in the BC.Net)
I wasn't surprised when I read that the BC.Net is no longer recommended to be used directly. The future is services + WCF. I would even say, that the use of the BC.Net should already be avoided whenever possible today. The AIF does offer you many possibilities for doing it today and the standard Ax client is for most other situations good-enough...

PS: And don't forget that there is no COM.BC available with Dynamics Ax 2012.

No comments:

Post a Comment