Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Richard Maher" Newsgroups: comp.lang.java.programmer Subject: Re: Java servlet on browsers: dying or kicking ? Date: Sat, 5 Jan 2013 08:22:42 +0800 Organization: HTTP *is* The Box - Let's think outside Lines: 87 Message-ID: References: <50d892e5$0$282$14726298@news.sunsite.dk> <50dbf6d1$0$80176$742ec2ed@news.sonic.net> <50dcfecc$0$292$14726298@news.sunsite.dk> <50dd5b51$0$80184$742ec2ed@news.sonic.net> <50de2260$0$293$14726298@news.sunsite.dk> <50df9c4b$0$284$14726298@news.sunsite.dk> NNTP-Posting-Host: jOhPn0KFjrxwuMc9OPMmCw.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Response X-Notice: Filtered by postfilter v. 0.8.2 X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 X-MSMail-Priority: Normal Xref: csiph.com comp.lang.java.programmer:20960 "Arved Sandstrom" wrote in message news:nUoEs.1$Z03.0@newsfe23.iad... > 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. >> >> Arne > > 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. > > 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. > > 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. > > 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 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 :-) As for vendor lockin it seems that Microsoft .NET is oft automatically excluded from this category for some reason. 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 :-( 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? > > AHS Cheers Richard Maher PS. Applets are alive and well.