|
OK, unless someone else jumps into this thread this is my last post on the topic. A back and forth between Joe and I (while fun) isn't all that productive. >From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx] >you ... can report errors immediately, because the client is on the same machine >as the business logic. Ignoring performance, you could report errors immediately in the web environment too. And as time passes performance is easier to ignore. The number of trips to a server (iSeries or otherwise) I'm willing to take in a transaction today is much higher than the number I was willing to take 5 years ago. >Where does this logic reside? Where would you like it. In a simple project you could put this on the web server. In a more complex project you'd have a business layer that did this. >How much of this do you store locally on the workstation? Define workstation. If you mean the browser on the clients PC, none! That's what sessions are for. >When is it edited? Again, when would you like it edited. You can edit after you add each line, or once before you post the order, or both (probably should be both). Also depends on the interface you choose. If you're on the click-to-buy model of Amazon then you check when you add the item to the shopping cart and again on the order creation. If you're in the subfile-entry model (enter a bunch of items and quantities and click submit) you'd check the items entered on click and again on post. Reporting back to the user and problems ("We're sorry, we've sold out of item 12345, it's due in stock on the 20th. Backorder, or try item 67890?") >Not to mention the fact that commitment control across multiple >files in an order entry system is very expensive and has >serious performance implications. Strange statement. I'd argue that the cost of not using commitment control in a multi-file update scenario is much higher than the cost of using commitment control. >And how often do you pass this hypothetical XML document... Again, how often do you want those error checks? >Once again, subatomic error checking rears its ugly head. Agreed. But that's always been a problem of any order-entry system. When do you allocate the inventory? If you allocate as soon as they enter the line, great. But if they cancel the order you need to deallocate (no problem) but in the mean time you may have lost another order because there was no available inventory. Then again, if you allocate at the end of the process you may find you're out of stock. I've doe it both ways. >It's clear to me that you haven't really designed one of these systems. If my design experience can be clear to you from a couple of quick e-mails we have a problem. As it happens I've designed a number of these (5250, client/server and web) over the years. >The concept of putting business logic on the workstation has been >demonstrated over and over to have fatal flaws, Hey, we agree on something <G> >And, in any event, you're NOT using the iSeries as a database machine. >You're using it as a business rules repository. OK, perhaps the words "use the iSeries like a large database" were poorly chosen. But my point was that you don't need a special toolkit to call a program, a stored proc call is just as good. >I hope you're not serious... the concept of triggers doing business >logic has been out of favor for some time now, Walden. All depends on what you use the trigger for, but in this particular case I would agree. I would have build the inventory allocations into the stored procs. Note the <G> >Yeah, you have the problem that you'll be running Windows servers. I'm in good company. >The number of servers that support ASP are FAR fewer than the number of >servers that support JSP/servlet. Thus, ASP is the non-standard >approach. I'm not sure how the number of servers available to me addresses the UI problem. My UI is on the client side, no? I consider the web-server part of my back-end systems. >I am considering side-by-side testing of Web development in .NET and >JSP, using VS.NET and WDSC. My question is whether you consider VS.NET >Pro to be as productive for ASP development as WDSC for JSP. In the correct hands, yes, one is as productive as the other. Be careful doing you own comparisons though. You know JSP quite well, you're going to be more productive with JSP regardless of the tool. I know ASP.NET will, I'll be more productive in ASP.NET regardless of the tool. You'd need to compare a JSP person with WSDC to an ASP.NET person with VS.NET. (And no, I don't have the time to try a code-off) One parting note. I don't believe JSP/Java is a bad choice, that's not what I'm saying. I simply believe that ASP.NET is as good a choice. Here's my prediction for app dev in 3 years: 45% in Java/JSP, 45% in .NET/ASP.NET and 10% in everything else. -Walden ------------ Walden H Leverich III President Tech Software (516) 627-3800 x11 (208) 692-3308 eFax WaldenL@xxxxxxxxxxxxxxx http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.