Re: Java servlet on browsers: dying or kicking ?
On 1/4/2013 7:22 PM, Richard Maher wrote:
"Arved Sandstrom" <asandstrom2@eastlink.ca> wrote in message
news:nUoEs.1$Z03.0@newsfe23.iad...
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.
I think a perceived problem with your incredibly resonable arguments Arved
is that the primary objective in most (certainly .NET) IT depts today is to
eliminate SQL altogether and nothing to do with user/business requirements.
Your reference to their anathema of Store Procedures and Referential
Integrity to enforce business rules and logic would rule out Code-First
which is the Holy Grail of OO sites. Technology and fashion is paramount
here. Fit-for-purpose can often be a nebulous concept subject to whimsy and
subjectivity :-)
In both the Java and .NET world ORM's with no SQL are popular.
And in my opinion they are a very good choice in a majority of cases.
But they are not a good choice in all cases.
And using an ORM does not in any way preclude putting well let me
call it integrity logic instead of business logic in the database -
constraints, triggers and views work fine in this environment and
even SP's can work in some cases.
As for vendor lockin it seems that Microsoft .NET is oft automatically
excluded from this category for some reason.
True. But the price tag of that is not so bad. The biggest risk is
that MS change direction.
And forget about the worry of
including business rules in different layers, I regurlary see the same
business rules and almost identical classes duplicated in project after
solution after application. Code Reuse (like the GAC) just seems to be in
the too-hard-basket. Easy-to-code seems to be the overriding requirement,
just look at ODATA :-(
Trying to put all business logic in application tier certainly do not
protect against all bad things.
And it is a lot easier to duplicate classes between different
systems than it is to duplicate the production database without
being caugth.
But let's say they put all the business rules in the Business Layer
implemented in a Java or C# class. Who is going to inforce thos rules from
PHP Perl or Python access?
Nobody.
In that case business rules in the database is a solution to a problem.
Another solution would be to go SOA and only let one service access
the database and let the rest interact with that service.
(I am pretty sure that the success rate for the first solution is better
than for the last solution, but SOA will also improve over time)
PS. Applets are alive and well.
It is alive.
Well? It is far behind several alternatives in usage.
Arne