Is there always a clear line between front-end and back-end of a software?

Question

Given a software, Is there always a clear line between front-end and back-end of a software?

Maybe it can be split into two more parts or split at a different border.

Answer 1

Hopefully yes, but pragmatically no.

Ideally, all functionality would be separate from its presentation, but experience has told me that this ideal is not always achieved due to either time constraints or system limitations.

For instance, consider a dinky little GUIified command line app. Sliders or text inputs may trigger backend code to fire, but that code may be intermingled with code that sets UI components, for example.The difference between the front end and back end is blurred in this case, as the same methods are called to handle "back end" and "front end" behavior.

Unless you're talking about server/non-server communication, front-end/back-end doesn't really mean much anymore. I have a flex app that makes posts against a server periodically. Surely the flex is the frontend, but it also provides significant functionality and business logic for the user. Does the flex have a "back end," or is the server the "back end?" On that note, what if the server just proxies to another web service? Who's what in that situation?

The terms are loaded at best, and it's probably better just not to think about it.

Answer 2

Splitting a software system into more than two parts is definitely possible, very advisable in many cases, and indispensable for sufficiently large and otherwise-complex systems; the special case in which the tiers are exactly two, back end and front end, is in fact pretty rare. For example, the database/persistence tier is often best kept separated from business logic -- indeed such a tier might be used by both the business logic (to persist entities of business relevance) and the presentation layer (to persist per-user choices related to such purely presentational issues as fonts to use, layout details, colors, etc).

It's generally the case that the layers, while distinct, can still be usefully grouped into two categories -- ones related to presentation and user interaction ("front") and ones not related to such issues ("back"); like all taxonomies, of course, even this simple one may prove to be an oversimplification in some cases (e.g. applications where presentational issues are strongly tied to the main business point of the application, such as desktop publishing, typography, some kinds of image and vido processing apps, &c).

Apart from such special kinds of applications, "contamination" among the tiers or categories is generally due to a desire for alleged optimizations; such optimizations often do not materialize or prove premature (optimizing some operation that has no real impact on the system's overall performance), so any technique which makes the system brittler, harder to evolve, and more complicated in the name of optimizing some aspects of it must always be evaluated critically (and this kind of "contamination" definitely falls in this group); however, in some cases (rarer than many think, but not non-existent), careful profiling and measurement will indeed prove that a certain "architecturally unpleasant" optimization is indispensable to the system's proper operation.