Generic Handler vs Direct Reference

Question

In a project where I'm working on the data access layer I'm trying to make a decision how to send data and objects to the next layer (and programmer). Is it better to tell him to

1. reference my dll, OR
2. should I build a generic handler and let him take the objects from there (i.e. json format)

If I understand correctly, In case of 2. he would have to handle the objects on his own, whereas in case 1. he will have the entities I've built.

Note: It is very probable that other people would need to take the same data, though, we're not up to that yet. Same question here - should I make it into a webservice, or have them access the handler?

Answer 1

The answer is "it depends".

If you are building a tightly coupled system where your team has full control of the various layers, then you're probably better off having him reference your DLL. This will usually offer the best performance and as you say, he will be able to reuse the entities you have created.

You mention that other people may need to use the same data. This is where a service oriented approach could provide dividends especially if they will be making calls from servers you don't control or where it would be difficult for them to get copies of your binaries.

Finally, there are cases where you might consider doing both. Based on the language and frameworks you are using, it might be pretty easy to provide direct DLL binding to those on your own team while also supporting an API (JSON or whatever) for external callers.

Answer 2

It's hard to offer concrete advice without knowing more about your ecosystem.

An approach similar to Bryan's that I've seen work was in a WCF solution. There, we published a DLL that defined serialized data objects (POCOs) that our service code also consumed.

Other applications could also import that DLL and use our objects. In the case of non-.NET service consumers, those teams implemented their own serialization objects based off the WSDL.