|
> From: Walden H. Leverich III > > >From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx] > >Most non-trivial solutions require a non-trivial > >approach, such as a message-based client/server system. > > So your non-trivial green-screen application from 1992 was a message-based > client/server system? No, Walden, because they are dedicated green screen terminals. OLTP is different than distributed processing, which is my point. With a dedicated OLTP terminal, you have control over the transaction flow and can report errors immediately, because the client is on the same machine as the business logic. You want to get into architecture? Fine with me. > >For example, how do you create an order entry system using only stored > >procedures as entry points? ... > > Are we discussing architecture or technology? But... We're discussing application design, and why using the iSeries as a database machine is a bad idea. In a broader sense, we're discussing why any ODBC-centric application is a bad design. > Allocate Connection > Begin Transaction > Create Order Header > Add Ship To > Add Ship To > Add Order Line > Add Order Line Ship To > Add Order Line Ship To > Add OrderLine > Add Order Line Ship To > Add OrderLine > Add Order Line Ship To > ... > Commit Transaction > Deallocate Connection Where does this logic reside? How do you get all of that information to the host, and when? How much of this do you store locally on the workstation? When is it edited? Since the order entry needs to be atomic (that is, the entire order must be committed at once), how do you perform subatomic error checking? Not to mention the fact that commitment control across multiple files in an order entry system is very expensive and has serious performance implications. > Simple No? Or, you could simple bundle the entire order into an XML > document and call a stored proc passing the XML doc and let the > stored proc do it all. And how often do you pass this hypothetical XML document, Walden? Once again, subatomic error checking rears its ugly head, unless you're willing to design a system where the customer enters their entire order only to find at the end that they botched the customer number. It's clear to me that you haven't really designed one of these systems. I've developed about six over my career. The concept of putting business logic on the workstation has been demonstrated over and over to have fatal flaws, while the idea of using something like ODBC as a funnel for client/server is simply using the wrong tool for the job. Take the time to write a real client/server environment, and now you've got all of your options. And, in any event, you're NOT using the iSeries as a database machine. You're using it as a business rules repository. You're just funneling it all through ODBC because you're... well, for no good reason I can see. > Oh, and don't ask me where I'm allocating the inventory, that happens in a > trigger based on the order line table. <G> I hope you're not serious... the concept of triggers doing business logic has been out of favor for some time now, Walden. > No argument. So if I know I'll be running Windows servers on the back end > in 3 years I don't have a problem, right? Yeah, you have the problem that you'll be running Windows servers. But that's a different issue. You want to run your mission critical systems on Windows, you have a different mindset. > >And in the problem set of UI, ASP is far less standard and far more > >restrictive than JSP. > > Huh? Currently they both feed HTML devices, no? Aren't we restricted to > the same UI in HTML? Also, if you refer to the fact that you could >create XML or some other ?ML, great, so can ASP. 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. > >Personally, I couldn't care less about standards committees... > > Fine by me. I was simply answering your statement that you couldn't > justify > spending $1000 on a "non-standard web development platform." You must have > a standard to be non-standard, no? No, I'm using the Microsoft philosophy: market share equals standard. At least that WAS the MS philosophy until they got religion and decided to submit CLR to a standards body. > >Thanks for pointing that out the competitive upgrade, Walden! > > No problem. However, I'd argue that even at $1000, if you can't justify > spending $1000 on your $60K developer to write your web app for your $100M > company then you have a problem. (Editorial use of "you", not you > personally Joe) I was talking about me personally. > >So, in your opinion, is VS.NET Professional equivalent and/or better than > WDSC? > > Better for what? I wouldn't choose a technology based on the IDE. If > you're going with JSP then VS.NET will suck, and if you're going with > ASP.NET WSDC will suck. My point was simply that MS has a _very_ good > IDE should you go that way. 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. Joe
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.