Exposing multiple assemblies as single API

Didnt really consider this aspect till I started building my solution...

To simplify, my application exposes an API to be used by other applications. The API is conceptually comprised of two parts: "Action" classes, and data type objects. Each of these is in its own project.
(I'm not asking now about class design, thats a whole separate issue - there are good reasons for this.)

Now, one of the main reasons these are in separate assemblies, is that internally they are used very separate from each other: the data types ARE used internally, extensively - however, the action classes are simply the public face of the application, and NOT used internally at all.

So far, all was good, it all made sense...
Then I started plugging in the API, and realized - calling apps would need to reference TWO assemblies, instead of just the one, in order to use the API.

So what would be the best move here?

Leaving two separate assemblies, as their internal logic demands - and forcing our clients to perform an extra, unrequired and unpretty extra step.
Commingling between usages of the two assemblies, and building only a single assembly. This would mean the internal classes will need a reference to the external API... and this might lead to circular references...
Some other brilliant solution (which is really the answer I'm hoping for?)

Reeeheely hoping for something new in the area of 3... thanks.

This wouldn't work at all. The assemblies referencing the 3rd assembly would need to reference the "data" assembly in order to pass arguments and receive the return of the API.

Ciwee 2010-01-12 01:34:39

I didnt quite think that through. I think I would build the API into a separate assembly anyway to keep it separate and have 3rd parties reference all 3 as it wouldnt bother me. I know this doesnt answer your question. Appologies.

Mark Redman 2010-01-12 01:52:49

@Mark: As I see this, the Action assembly is already the API and the data assembly is the only other assembly that would need to be referenced. What sums 2 assemblies needed and not 3. He is asking how to work around the 2 references.

Ciwee 2010-01-12 02:01:53

I see, in that case it wouldnt bother me to reference the 2, or have 3rd parties reference the 2 assemblies. So I guess still go with No. 1 in the original post.

Mark Redman 2010-01-12 02:22:33

@Mark, thanks, would you not find it cumbersome to have to consume double references, just to make the API useful? I mean, some of the API parameters and stuff will be types from the datatype assembly, so its useless (and cant even compile) unless you hook them both.

AviD 2010-01-12 11:50:21

I should have also pointed out, that this is for packaged software - for enterprise systems. Thus the expected level of polish is a bit higher...

AviD 2010-01-12 11:51:26

@AviD: I absolutely agree what you're trying to do, it does make things cleaner having a single dll, but as long as its documented and works it doesnt really matter that much. Once its referenced it's referenced. Developers will soon figure this out. I would certainly not try and add additional build steps to merge things to get around this. (This is just my opinion)

Mark Redman 2010-01-12 13:24:41

@Mark, it wouldnt bother you having a split part API? it just seems.... *unprofessional* to me. It would smell funny to me, if I was the user here... I wonder what others here think? Do you have any example of 3rd party APIs that require more than a single reference?

AviD 2010-01-12 18:27:18

Also, I want to point out that I'd be willing to take on some more complexity internally, to make it easier/better/polisheder for my users, and I'm really trying to remove as much friction as possible. Don't forget, in some of these big enterprise systems, dozens of projects per system is the norm, and each one would require all the references, not to mention future versioning, etc.

AviD 2010-01-12 18:28:52

@Mark, I'd mark your comment as accepted answer, but not the original response :)

AviD 2010-01-19 02:07:18

@Avid: Updated answer to reflect conversation...

Mark Redman 2010-01-19 09:34:22

@Mark, I accepted this answer, simply cuz I dont see any better answer. I'm still not convinced that this is as "polished" as can be.... Do you happen to have any example of 3rd party library like this?

AviD 2010-01-19 18:47:21

We use various 3rd party libraries where we reference multiple dll's: Xceed Zip components, ActiveReports Reporting tool, Tall Components PDF Library and the NetZtreme mail components.

Mark Redman 2010-01-20 10:59:41

It may lead to circular reference as he stated

Ciwee 2010-01-12 01:43:02

That's a design problem. If right now there aren't any circular references, merging them into a single assembly (either manually or with ILMerge after they've been built) should not introduce any.

Robert Fraser 2010-01-12 04:16:24

@Robert, re the circular reference: Consider that the action class relies on a (lets call it) Server class, which relies on the datatypes assembly... problem would be having the merged API assembly rely on the Server class, which relies on the merged API assembly... Hence, introducing circular reference.

AviD 2010-01-12 11:48:28

ansaurus

tags:

views:

answers:

Exposing multiple assemblies as single API

related questions