Re: Java servlet on browsers: dying or kicking ?
On 12/31/2012 6:06 PM, Arved Sandstrom wrote:
On 12/29/2012 09:43 PM, Arne Vajh?j wrote:
On 12/29/2012 7:22 AM, Arved Sandstrom wrote:
[ SNIP ]
I emphatically don't delineate layers by technology used, or even by
location. A clean, understandable architectural picture can deal with,
and explain, business logic in Javascript on a mobile browser, and also
business logic in a DB stored procedure.
Business logic can be put in all tiers.
But it may not be equally good design.
There are several schools of terminology here, Arne. I hold to the
school that says that a "tier" is a physical division in a system
(hardware/software) architecture, while a "layer" is a logical division
in a software architecture.
That is the definitions of tier and layer I prefer as well.
So that's why I said what I said the way I said it, using the words
"layers", "technology" and "location" on purpose. I think that as long
as your business logic is identifiably in a location where it should be,
then you have a sound solution (all other things being equal).
In any case we commonly have business logic in the data tier. A subset
of business logic is business rules, and one category of business rules
is data constraints. And data constraints, as you know, are very often
imposed directly in an RDBMS or managed indirectly through JPA or its
.NET equivalents, to use just a few examples.
Since we - software developers in general - routinely do the above, I
see no reason to demonize business logic in stored procedures either. In
fact, given the efficiency of a modern RDBMS in handling DML it is
frequently the most sensible place to put certain kinds of business logic.
SP's are certainly a valid option for business logic.
The biggest drawback is the vendor lock-in (unless it is an
open source database, which the SP based solutions rarely are - it
is almost always Oracle/Microsoft/Sybase).
To be honest I've been uncomfortable for a long time with the label and
concept of a "business logic" layer, as opposed to say DALs or
Presentation layers. For example, workflow is a component of business
logic - in order to adhere to orthodoxy you have to then maintain that
every aspect of workflow in web apps, SOA orchestrations or mobile
client apps is still business logic.
Which probably it is - in which case why is Javascript business logic a
bad thing? I've worked in a bunch of shops where to utter Javascript and
"business logic" in the same sentence occasions gasps of horror. :-) And
yet many of these same people have methods, that are directly exposed
through JSF web pages, also doing business logic. I'm not indicating
strongly here what I advocate and what I don't, I'm just saying that
business logic permeates every tier we have, so maybe the concept of a
"business logic" layer needs some thought.
We need to distinguish between client tier vs app server tier and
JavaScript vs other language like Java.
Code running in client tier is cooperative not enforcing in nature.
I see that as a major problem for business logic in many contexts.
It applies equaly to AJAX JavaScript, Java applets, Flash,
SilverLight etc..
JavaScript is a different language than Java. I am not convinced
that it is a good language for business logic. But other may have
different opinions. I will not though that the existence of
new languages like Dart and TypeScript shows that I am not the
only one with such concerns.
That applies equally to client side JavaScript and server side
JavaScript (node.js).
I think at a minimum a developer needs to understand what business logic
is - rules and workflow - and needs to adequately manage where it is. I
think it's less important what tier it's in.
I don't agree.
What tier the business logic is locate in can have huge architectural
impact.
Arne