Menu
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.
489
Typically libraries stay static within the development of an application, at least besides occasional upgrades: application code utilises the functionality provided by the modules to create a specific behaviour for the logical interaction between users and a domain of data in a generally tighter-defined environment.
Application code is a series of SQL statements that process input and produce output. These SQL statements operate on in-application streams and reference tables.
The technical difference between a framework and library lies in a term called inversion of control. When you use a library, you are in charge of the flow of the application. You are choosing when and where to call the library. When you use a framework, the framework is in charge of the flow.
Library code is organized in such a way that it can be used by multiple programs that have no connection to each other, while code that is part of a program is organized to be used only within that one program.
Library's code is intended 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, will this code remain?
84
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.
36
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?
36
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
