On 12/31/2012 08:29 PM, Arne Vajh?j wrote:
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).
And that's one of the few disadvantages. The big advantage (shared with
views) is centralization of data access logic - rather than having every
client doing the same D.A. manipulations, you've got complex stuff
bundled in one place.
This also eases the security problem.
On the subject of vendor lock-in, I'm not that worried about it. No
matter what software you pick, whether proprietary and $$$, or gratis
and open source, once you've invested some application effort into a
given product then you have a degree of lock-in. And in my experience
substantial underlying systems just aren't swapped out that frequently.
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.
Maybe I'm obtuse, because I don't see the problem. In fact I haven't
wrapped my head around the "cooperative" and "enforcing" labels either.
Let's assume a relatively thick client, so that there's some application
logic to speak of on the client. That client logic could be as complete
as being UI + process logic + a subset of domain logic + an embedded DB
for independent operations, or it could be pretty spare and only have
some UI and a bit of process logic. Either way, when it communicates
across the physical (tier) divide with the server, it's an _internal_
detail. If you've got a proper internal API to handle that physical
boundary then what's the problem exactly?
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.
If we're talking tiers and not layers, and let's say we think of the
client, middleware/server, and database/data access tiers, I am hoping
that the decisions to locate business logic in any of those tiers leads
to positive architectural impact - otherwise why are you locating logic
there?