Say I have a service that has the following hierarchy:

  • Controller
  • Business Logic
  • Data Adapter

All of these make up a service that presents an HTTP API that can be used by other services. Together these layers form a functional piece of an application.

Does it make sense to package each of these layers together as 1 versioned unit? Or to package each individualy with its own version and then consume eachother as a package dependency using NuGet for example. Controller consumes the business logic package which in turn consumes the data adapter package.

Would there be any benefit over the other?

Essentially what I'm asking is should packages be left for shared code across many services/applications or should the guts of a service also use packages to manage its internal dependencies in its own stack?

  • Assuming that there's a routine way to deploy a project's DLL to a specific machine (e.g. by copying it to a specific folder), I don't see all that much of a difference. – Robert Harvey Feb 12 '15 at 1:24

It depends on your application.

For example, I have a product that comprises a server installation which is several services, and a client application. We package these as 2 pieces - whilst each of the server side components could be installed individually, nobody ever does (or will) so it makes sense to install them as a single item. This allows us to reduce the effort required in making different versions of these pieces works together.

However, nobody likes upgrading the clients as it requires an engineer to visit some remote sites, so we install those separately and ensure old clients can still talk to updated server.

So we have half a dozen components, but these end up as 2 installers. Its all down to your system, and your dependancy management between them. It also depends on your customer- if these packages are being created for developers, then maybe it will make sense to package each one up individually to allow changes to be acquired quicker.


If you will have other "UIs" (the web service can be thought of as the ui part of your application) then it may make sense to package the BL and DAL as one package and have your service (and other UIs) consume it. Otherwise its easier to treat everything as a single unit.

You might also consider if you will deploy new versions of the service while leaving the one ones running as separate applications as well. In that case you have multiple UIs (each version installation) but you may have to deploy them with later versions of the BL and DAL (if there are db changes for example).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.