I notice there are two Asi assemblies that seem, on the surface at least, to serve the same function - to provide an API to expose contact information to a .Net application:
- Asi.iBO
- Asi.Business.Contact
Looking under the covers at the implementation, Asi.Business.Contact seem to be based on Business Objects, whereas Asi.iBO, erm is not.
So my questions:
- is one a superset in terms of functionality of the other?
- what features does one assembly provide that the other does not?
- which assembly do Asi "prefer" us developers to use?
- is using both assemblies in the same application a good idea - for example will the IPrincipal created by one assembly stomp on the IPrincipal created and assigned to Thread.CurrentPrinicipal by the other, thus making it difficult in practice to use both assemblies in the same .Net application?
Thanks
Christian Crowhurst
The major difference is
The major difference is that, at least for now, you shouldn't use Asi.Business.Contact. :)
In more detail, yes, Asi.Business.Contact is based on BOD, specifically the Contact object. This object is used by a few modules within iMIS (mostly within the Marketing Suite IIRC), but it has some major limitations: specifically, that it doesn't know anything about the contact tables used by iMIS Desktop, eSeries/eCM, etc (i.e. Name). It only knows about the ContactMain, Individual, and Institute tables.
Asi.iBO, on the other hand, uses the same tables as iMIS Desktop et al, meaning any data written using it will be 100% compatible with those other applications. It supports all the same business logic, including flowdown etc, while to my knowledge Asi.Business.Contact is a pretty barebones implementation (it's still in the early stages of development, as best I know).
In general, ASI's recommendation is to use Asi.iBO for any functionality you can, since that product is fully supported for third party development and should only change minimally between iMIS releases. If there is no iBO coverage of a particular feature, then using a typed class based on BOD, or custom BOD objects, is recommended over direct SQL access. (This guidance may change in future versions, obviously.)
In general using a BOD-based object in the same app as an iBO-based one should be fine; the iMIS application and public servers use a mixture of those APIs, for example.
Eric Means
System Architect, ASI