Board index » delphi » Re: ASP.NET: Fundementally Flawed Architecture

2006-03-20 07:24:58 AM
delphi205
"Dennis Landi" <XXXX@XXXXX.COM>writes
Memory management? Complexity? You're telling me these are better in a
natively compiled environment. How exactly? Also you don't mention a
platform. Just saying Delphi or C++ doesn't tell me how you're developing
your server code? Writing an Http Server from scratch? Using Intraweb?
Writing ISAPI DLLs in C++? Other?
-trevor
 

Hadi Hariri writes:
:-)
JoeH
 

Trevor de Koekkoek writes:
it. Very few lines of code. Very performant. There are plenty of 3rd
party tcp-ip delphi socket servers in the community, so there is no need
for you to roll you own from scratch (although its not hard).
I have NexusDB hooked up as a back-end, so even the DB server is 100%
native Delphi. The unit that integrates a full set of NexusDB services
into my webserver for my Flash WebApp amounts to no more than about 400
lines of code. I could of course use most other DB products as db
back-end with no real impact in the size of complexity of code in the
webserver. But I do love the fact the NexusDB is 100% Delphi.
The servers (both web and db) are fully multi-threaded with a very small
foot-print. Installation is as easy as dropping an exe on a machine or
installing them as a service...
No fuss, no muss, lean, mean and clean...
-d
 

Henry writes:
Winforms? Delphi VCL forms?
 

might work well for your flash applications, but having the .NET framework
for XML processing, state management, and ease of development to name a few
can't be matched by what you describe. I have used low-footprint Delphi
webservers as well. But they aren't appropriate for complex applications
IMO.
-trevor
 

Trevor de Koekkoek writes:
management on the server when using Flash, and Flash has a full arsenal
of XML services including WebServices (although those, too, aren't
necessary with a Delphi Server, unless you want to support Web Services
for some customer oriented reason).
-d
 

and ASP.NET as well. You haven't shown me in any way how Delphi + Flash is
any better than ASP.NET + flash except possibly speed and footprint. The
XML processing I am talking about is on the server and for robust
applications you're still going to need processing on the server. I don't
see how memory management, ease of development, maitenance, etc. is any
better in a natively compiled app. Memory management for one is far easier
in a managed application and server-side XML processing (XPath, XSL, etc.)
is far more robust in .NET than in Win32 Delphi.
-trevor
 

Trevor de Koekkoek writes:
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 have 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 don't use XPath, but I dare say, I would look for a lean, mean and clean
native delphi Xpath Module to plug into my application, before I would
abandon my native delphi code just to get XPath.
And that is all I will say about the thought processes concerning
technology choices. I suspect there are other quite specific forces at
work causing you to make the choices you've made, but I don't think they
have much to do with laying out the pros and cons of technology platforms.
-d
 

"Dennis Landi" <XXXX@XXXXX.COM>writes
indicated any ways in which Delphi is better for web development. I've
asked you repeatedly as to how it is better other than possibly in speed and
footprint. How is it easier to develop? how does it handle memory better?
How is it easier to maintain? and others of your own list of 9 points? As
far as mean and lean native Delphi for XML you are assuming somehow that
.NET is slow. It might be slower than native code but often the difference
is not noticeable and then you must take into account the practicality of
having a very robust framework vs. searching for custom less supported
components. Sure it is doable, but how is that more maintainable and more
productive? Again using your own criteria for assessing a technology.
-tdk
 

"Dennis Landi" <XXXX@XXXXX.COM>writes
flash client-side development which I am not disputing and which I've
pointed out can be done with ASP.NET or native Delphi. So we really are
getting no-where with you not answering my questions. So I think I am out of
this conversation, but I hope to engage in others with you in the future.
Thanks,
Trevor
 

Trevor de Koekkoek writes:
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
 

luxspes writes:
.NET like that; good for whiz-bang demos, but useless for real work.
 

David Farrell-Garcia writes:
an extremely artificial component model on top of the HTTP protocol. HTTP is not
the Windows message loop, and trying to pretend that it is is asking for trouble.
 

Mmm, you can do states in ASP.Net
there is a dedicated chapter in every book about ASP.Net development
how it was with DataSnap when STATELESS server is used, same with ASP you
need to do a little of coding to specify a way of how state is preserved,
but it is there and used widely...
"Henry" <XXXX@XXXXX.COM>writes

I use firefox and the 2nd plugin i install after noscript is a flash
blocker.