Hello again, Terry.

>>Don't now about that article, but by the author name, he's probably biased. 8-)
>http://www.informit.com/content/index.asp?product_id=%7B47A49B11-A547-44DE-87F7-92C0D32E78DF%7D&051803

I can't find anything in this article that support any concern about n-tier architecture. Indeed, it doesn't even tackle the issue. It's title is: "Designing Framework Applications: Using Design Patterns with VS.NET Framework Applications"


>>
>>Fear not. Believe me that VFP is MANY times a better tool to develop n-tier apps than VB, both on the data, middle, and user tiers.
>
>We're talking about the VFP data engine - of course the GUI tool is great! But, so is VFP's record pointer and reiterative record service.

I think that here we have our main point of disagreement. I think record manipulation is good for local, in-memory, small resultset data. It is an overkill (I borrow your term) in most situations *except* in *some* very small yet powerful networks. In any case, its own flexibilty is the main reason of its problem: record manipulation over the network have the annoying tendency to end up in data corruption.

>>You should try to follow his reasoning. I'd be better trust in a smart guy knowledge than in my own ignorance. ;-)
>I make my own judgements - other views can be helpful - but - they can also be a product of ignorance, un-supportable bias, and a major pita :-)

I'm not asking you to take his word or anyone else for granted. I just say that if you recognize your own ignorance about some topic, and a person that you consider smart and knowledgeable gives you an idea that has the potential of benefiting you, then it's not a bad idea to reconsider and gather more information to make your own judgement, prior to make bold statements.

>>I don't understand that last sentence. Do you mean that n-tier apps are slower? That's not true at all. N-tier apps can be slower of faster than monolithic apps, just depending on how well they are designed and built. This architecture issue is not guarantee of performance at all, but in some circumstances, n-tier can be a LOT faster than a monolithic app.
>
>Read the article about tiered vs layered - most VFP apps are layered - which implies a tiered architecture without the requisite physical seperation of services. Layered apps are a logical seperation. Tiered APPs are a logical as well as a physical seperation. In most operations, a tiered solution is not required, unless, of course, you are suggesting that a small business with 15 or 20 desktops in one office, switch to an Access backend (they ain't gonna buy SQL and a DBA!), just so a VFP developer can lockstep with the nTier evangelicals:-).

I'm sorry but we have a series of misunderstandings here: n-tier architecture doesn't implies that you have to physically separate tiers, so what you -or the article you read- calls layered architecture is just non-distributed n-tier architecture. But the principles are the same, and this is one of the premises: the distribution of each tier does not matter, as far as you can distribute them at any time without major code refactoring.

>What is a monolithic app?

An application that does everything in a single tier. For instance, many typical apps where a form has code in a button that opens a table, reads some records and perform a calculation. This is user interface, business loginc and data access all in the same tier, and this is what I'm stating as a potential problem. What if your small customer ask you to put up his simple order entry in a web page? You have to rewrite most of the order entry logic in other place. If you went n-tier in the first place, you just write a new user interface tier (typically VERY little code), and you're done. Any change in business logic or data access would have no impact in any of the two user interfaces.


>>I think you think n-tier architecture is something complex and snobish.
>
>No I don't - if we are writing apps for a mult-national or broad based user - then sure - ntier may make sense.

Again, you think that is more complex than it really is. There is no difference if you're writing a simple one-screen expense tracking app or a large enterprise app. Not in the basic principles. Once you have your framework in place, and if you did it right, your can go faster and cheaper with n-tier.

>>This is something like saying that OOP is slower and most costly than procedural code.
>
>OOP is just a means to reference and point to 'procedural services'. OOP, without procedures (or methods) is like a shower without water. OOP would not exist unless procedures were available to do the work.

I'm sorry, but this is not true. OOP is a totally different approach than procedural programming. The fact that in the end an OOP app or a procedurally written app both end running in the same mashine code has nothing to do. The two approaches are radically different, and as OOP makes much more easier code reuse, abstract modeling, less coupled component, etc, n-tier does something simmilar in terms or system architecture.

>>Please, take the chance to know about it a bit more. I think you'll realize that you have some basic misunderstandings. If not, I'll be glad to know your good reasons against n-tier.
>
>No reasons against n-tier, except that most of the market doesn't need to buy it. Are you saying all projects should be tiered. Isn't that a bit of an expensive overkill?

Based on this criteria, you could also say the market doesn't need OOP, graphical interfaces, or relational databases. But this is not true. All this technological improvements led to easier to use, cheaper to develop, more maintainable and extensible software. n-tier is just another step in that direction, and a quite old one, indeed.

Can you avoid it? Of course. You can also keep writing procedural code instead of OOP, plain text files instead of realtional databases, and achieve a fair product, but... would you do it?