views:

61

answers:

3

This question sprung from a web application, although it should be valid for other types of applications too. I am using MVC.

I have both application code (modeles, views, controllers, forms, helpers, etc.) and library code (external libraries and an internal library with self-written database mappers, json converters etc.).

I wonder where you usually draw the line between application and library code (when both is internally written)?

Some of the library code gets rather project specific, but is still a bit abstracted.

+1  A: 

My general rule of thumb is: Anything that might ever get used in another project, and can be made to easily not depend on any application-specific code (and there are all kinds of techniques to do that) should go into a library. So if it is potentially reusable it goes into a library.

Adam Batkin
+1  A: 

library's code is intented to be reusable, application's code usually not. Keep code in a library when it is not tied specifically to the application.

When in doubt try to answer this question:

if I write another application this code will remain?

dfa
+1  A: 

When faced with these kind of categorisation questions I want to know one thing: the consequences of miscategorisation.

This code is "library", that code is "application" ... for whose benefit is this distinction being made? What would happen if we put some code in the wrong category?

One possible answer:

It affects the reuse of the code. Lets suppose that we have a policy: library code is available in a DLL with the required headers etc. Application code is just deployed in a .EXE.

Put a nice routine for doing a difficult calculation in the App, not the library, then it can't readily be reused.

Perhaps further things follow from that line of thinking ... questions of versioning apply. Do we need to produce better documentation? [Even with a single developer we might take more care?] Do we need to externalise configuration information, mak doubly sure not to hard code anything?

djna