Re: ASP.NET: Fundementally Flawed Architecture

Trevor de Koekkoek wrote:
"Dennis Landi" <dennis@xxxxxxxxxxxxxxx> wrote in message news:441e1b00$1@xxxxxxxxxxxxxxxxxxxxxxxxx

Trevor de Koekkoek wrote:

"Dennis Landi" <dennis@xxxxxxxxxxxxxxx> wrote in message news:441e085e$1@xxxxxxxxxxxxxxxxxxxxxxxxx


Trevor de Koekkoek wrote:
So we've boilXwoad down your reasons for using ASP.NET to the availability of server-side XML processing? Do I have to point out that this has nothing to do with web servers or web applications, per se?

What's difficult about server side xml processing? I've been doing it for years, and I don't need to buy into a huge framework just to do xml processing. I do it with delphi servers and with Flash every day.



I mentioned XML processing as ONE example. You on the other hand have not indicated any ways in which Delphi is better for web development.

Because web server is far more simplified since it doesn't have to do the state or gui management. I've already explained this to you and it has not registered.

You don't seem to understand the incredible overhead managing the state and the gui from the server costs in terms of complexity, robustness and performance, let alone ease of maintenance. Since I've been writing web application servers since 1996 I know how to do it "the hard way" and what exactly the costs are in terms of servers-side complexity. With this managed by the web client, the web server is left alone as a conduit of file requests and DB requests. It because a much more simpler mechanism that does very little and as a result, it becomes much more robust and extremely performant since the tasks it is required to do can be done simply and quickly. As such, it then become an ideal server solution for high-load, heavy traffic internet websites with "real world" commercial demands.

This architecture also truly isolates the "middle tier" for what it is intended to be, for people who understand what they are doing. And that is reserving the middle tier for server side activities that really cannot be done in any other tier; because putting business logic in the middle tier is expensive from a performance perspective as it can become the performance bottle-neck in an architecture just like Db Servers run the risk of a bottle-neck.

However, there are cases where there needs to be a "broker" of some kind "coordinating" disparate sources of "state" and this where the middle tier entity becomes a necessity. As such a "WebServer" by nature can become a very simple, very specific "broker" with a very small portfolio of tasks. This is the secret to high performance, robustness and simplicity of design.

In my opinion, new developers are using "the middle tier" as a crutch very much the way client-server developers used the "database" as crutch 10 years ago. Over use of these tiers will result in unnecessary complexity and a degradation of performance as work is being done on the server when it could have been done on the client "at no cost".

However, even in web application scenarios there are situations where "special" tcp-ip servers with specific jobs can and should be deployed as separate middle-tier entities when the situation demands it. But the "broker's" portfolio of tasks should be clearly defined and adhered to so that it doesn't become bloated, complex and hard to maintain.



I've asked you repeatedly as to how it is better other than possibly in speed and footprint. How is it easier to develop?

Hopefully, I've just explained it.




No you haven't explained it. You've just pointed out again the benefits of flash client-side development which I'm not disputing and which I've pointed out can be done with ASP.NET or native Delphi.

No, ASP.NET (or any server) can't do client side state and gui management on the client, since its a server-side entity. A server side entity does work on the server. ASP.NET generates and sends its state and gui code to the client with each page request (or it generates server-side javascript to be executed in the browser in a limited fashion.)

IF you meant to say that Flash can act as a client for both Delphi servers and ASP.NET servers, then that is strictly true; but as I've already pointed out, the vast majority of "state" management and "gui" generation services are simply not needed by the flash client at all, so all Flash would be using ASP.NET for is an extremely bloated tcp-ip server.

In that case, why not use a lean, mean and clean, no-muss, no-fuss natively compiled delphi tcp-ip server?

"I know I would"...

-d




.

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • This is going straight to the pool room
    ... or not the client has privilege to do what they're trying to do, ... The server environment is this: ... 3GL User action Routines that Tier3 will execute on your behalf during the ... Routine Name: USER_INIT ...
    (comp.os.vms)
  • [Full-Disclosure] R: Full-Disclosure Digest, Vol 3, Issue 42
    ... Full-Disclosure Digest, Vol 3, Issue 42 ... SD Server 4.0.70 Directory Traversal Bug ... Arkeia Network Backup Client Remote Access ...
    (Full-Disclosure)
  • Re: What doesnt lend itself to OO?
    ... > rather than client code. ... no way to do that without also touching the object with clock semantics ... will not encapsulate both clock semantics and network semantics. ... The server can do whatever it wants ...
    (comp.object)
  • RE: Fax monitor incoming + outgoing calls?
    ... problem between the client computer and the SBS server. ... Client is using the internal IP address of the SBS server as the ... To the folder redirection GPO issue: ...
    (microsoft.public.windows.server.sbs)