|
> From: Booth Martin > > I agree. This conversation is silly. Labeling two bits of data > in the same > application as "unrelated" demonstrates just how differently you > and I view > data. I hope you don't really believe that all data is related to the same degree. How is a general ledger account description "related" to an item? These are unrelated pieces of data yet they may both need to be on the same inquiry (typically a profitability report). You need to use the item class (however derived) to get the account number, and then get the company number to in turn get to the correct chart of accounts so as to get the ledger account description. This particular logic obviously has no business in the general ledger server. It may tangentially belong to the item server, but only as an external inquiry function. It is really the combination of at least three servers in my architecture: the item server (which could conceivably return the item class information, though that's an issue), the company server, which will return the chart of accounts ID, and the general ledger server. If you have a single server for this procedure, then you're either duplicating code (code, for example, for posting an amount to a general ledger account), or else you're doing server-to-server calls. The latter is, in essence, what I spoke of as a presentation or data group server. It is fundamentally different from a business logic server. That's because it really has no business logic, other than defining the relationships between business classes. Your approach (one server to handle all data requests) only works when data is fairly simple. When things get more complex, you need more complex presentation logic, and that's what the presentation server does. But hey, if your code works for you in the real world, then I'm glad for you. I've always found that a presentation tier separate from my BL servers makes it even easier to design systems. > Further to that, I guess I really have no idea what a server is. Not the way I think of them, anyway. > I was not talking theory Joe. I was talking nuts and bolts > real-world stuff > So long as you slice vertically you are destined to a life of trying to > gain performance through hardware solutions. If you'll slice horizontally > you'll see performance improve, your programs develop faster, and they'll > live longer. I wasn't slicing vertically, other than trying to figure out how to get the same panel in two different applications. You seem to think it's essential to encapsulate all I/O in servers, yet it's okay to clone the DDS for a subfile and all the server code supporting it. Personally, I think that's silly. I think you can do both - create nice servers for presentation data and at the same time share panels among applications. > (by the way before you get to upset You are the one that chose "A design > philosophy question" as the subject line, not me. It sounds to me as if > your questions are specific questions about implementation, not > design. You > ve already decided your design.) No, I decided my architecture. Green screen. Multiple panels. Multiple display files, so panels can be shared among application programs. That's my architecture. Now I'm trying to design the implementation. You brought up the issue of horizontal and vertical modularization, and how my architecture doomed me, my users, and countless generations of maintenance programmers <grin>. 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.