application architecture in asp.net

[Guest]

Hi all,
I have couple of questions about architecting web application using asp.net

1. is ther any performance gain in using c# over vb.net
2. best way to handle transactions in .net? using ado level or COM+
3. I have looked at MS Data Access Application Block - where you return
DataSet/Data Reader as the value of the function - shouldn't that be by Ref ?

Thanks in advance.
CaptainDeep

 

[Marina Levit [MVP]]

1. No
2. If you don't need COM+, don't do it. That will of course not perform as
well as just ADO transactions because of the overhead.
3. I have never used it, so I can't comment. I would assume that enough
people are using it that the spec is correct, although you never know. If
you are just returning a value from a function, then I don't see how ByRef
is a factor.

 

[Karl Seguin [MVP]]

3. ByVal/ByRef don't mean what you think they do when dealing with a
reference object. When you are dealing with a value type (your own
structures, int32, bool, ....) then it means exactly what you think it does.
When dealing with everything else (dataSets, hashtables...) it's deceivingly
different.

When dealing with reference types, you are ALWAYS passing around the pointer
(or by reference). The difference though is that if you pass it ByRef, it's
the orignal pointer is passed. When you pass ByVal, it's a copy of the
pointer. In either case, modifying the argument will modify the original
object. However, if you modify WHERE the reference points to in ByVal, it
won't change the original.

Karl

 

[clintonG]

1. No

That's a lie. Both VB.NET and C# have performance benefits unique to each
language. The problem has at least three criteria...

1.) Microsoft MVPs are often liars; either simply too lazy to tell the truth
and discuss the facts or pathological liars that tell so many lies they
don't know how to tell the difference.

2.) Finding the real facts and determining how important the facts are to
application development is difficult, especially when there are so many
liars around and especially with the release of ASP.NET 2.0 which has failed
to produce lucid and trustworthy documentation. An application may
significantly depend on certain characteristics of a language that another
language does not support or does poorly.

3.) The big lie that is told most often is "the framework is the same for
both languages so it doesn't matter if VB is used or if C# is used."

That #3 is the biggest lie because it is false for reasons I've already
stated and it is also a lie because Microsoft is playing games by providing
features to support VB for example but not C# and then they provide features
that support C# but not VB. When one group starts complaining Microsoft then
adds the missing features to the language but it is then discovered they
only did maybe half of what the other language supported. They did this for
refactoring code for example when refactoring was first released for C#
which made the VB advocates start complaining. So Microsoft then they left
C# alone and made all kinds of refactoring support available for VB that C#
does not yet support unless buying it from 3rd parties.

Then the MVP liars tell their lies to deceive people instead of just telling
the truth.

This ca-ca de baca is getting old.

IMO C# should be used when developing web applications simply because web
applications require significant client-side script written using JavaScript
which is nearly exactly the same as C# so one learns three languages for the
price of one: Java, C# and JavaScript. AJAX/Atlas for example can be simple
to deploy but when extensibility is required mastery and expertise using
JavaScript is required. The developer that has learned C# then become more
productive as they already know how to use the syntax and grammar.

Finally, the .NET Framework has been a commercial failure for Windows Forms
development sold commercially because the source code is so easy to obtain.
Anybody can dispute that of course but to do so truthfully requires
answering the big question "Where are the commercial Windows Forms
applications sold by the main-stream vendors?" At this point we are
compelled to conclude .NET is a commercial failure for all but ASP.NET web
applications where the source code need not be exposed and as I contend the
use of C# is the wiser choice in that context.

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://www.metromilwaukee.com/clintongallagher/


<snip />

 

[Marina Levit [MVP]]

I disagree with this. For most of the things you would ever do, there would
be no difference. To start listing out all the scenarios under which one is
performing .01% faster confuses the issue.

I see few cases where language choice actually makes a difference in terms
of how fast your application runs. And in terms of providing support for
features and one language or another, that was not the question asked.

I find the argument that C# should be used for web applications because its
syntax is somewhat similar to javascript silly. Ok, it has curly braces,
but in reality, so much of the syntax is different, and what javascript can
and can't do is far different from C#.

In reality, if you chose one language over the other, your typical
application won't perform any different and your users won't notice.

You seem quite angry, and I really don't see a reason why. You sound like
you despise .NET altogether.

 

[Karl Seguin [MVP]]

Clinton:
I'm surprised by your views on this as a whole. I also think you are coming
down a little hard. Anyways...you have grievances maybe I can help address
them?

That aside, perhaps you could educate this ignorant helper about what
situations C# performs so much better than VB.NET? Maybe you're talking
about the ability to manipulate pointers directly? I neither consider myself
lazy nor a liar, but I would have given the same answer as Marina. Of
course, I still have a lot to learn, and I'm willing to in this case.

Karl

 

[clintonG]

The point to be made -- again -- is there can be performance gains using
features that are supported by one language and not the other at a given
point in time. That given point in time may not allow the luxury of waiting
for a preferred language to catch-up to the other. Perhaps the abscence of
the application may cost the company tens of thousands a day for example.
This is not unheard of. So should we wait until VB catches up to C#? Should
we wait until C# catches up with VB?

I've read comments from developers who have claimed generics for example
have improved the performance of their application. As you know support for
generics is an example of the leap-frog features that prove my assertion of
the facts. Who am I to say what language feature may or may not prove
critical at some given point in time? Regardless of who any of us are or
what we think we know or prefer does not change the fact that all that needs
to be said -- if being truthful -- is to explain the facts that language
features are circumstantial and without question there are indeed
differences between VB and C# at any given point in time just as there are
with other common type compliant languages.

Does repeating the lie that denies the facts over and over again make the
lie a truthful statement? Maybe Microsoft should rename the framework
SoundByte.NET because few care to simply explain the facts as they really
are. I've become sensitive to these principles lately.

<%= Clinton


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...

 

[Karl Seguin [MVP]]

Finally, we agree, there's no difference in performance between c# and
vb.net !

Karl

--
http://www.openmymind.net/
http://www.fuelindustries.com/

The point to be made -- again -- is there can be performance gains using
features that are supported by one language and not the other at a given
point in time. That given point in time may not allow the luxury of
waiting for a preferred language to catch-up to the other. Perhaps the
abscence of the application may cost the company tens of thousands a day
for example. This is not unheard of. So should we wait until VB catches up
to C#? Should we wait until C# catches up with VB?

I've read comments from developers who have claimed generics for example
have improved the performance of their application. As you know support
for generics is an example of the leap-frog features that prove my
assertion of the facts. Who am I to say what language feature may or may
not prove critical at some given point in time? Regardless of who any of
us are or what we think we know or prefer does not change the fact that
all that needs to be said -- if being truthful -- is to explain the facts
that language features are circumstantial and without question there are
indeed differences between VB and C# at any given point in time just as
there are with other common type compliant languages.

Does repeating the lie that denies the facts over and over again make the
lie a truthful statement? Maybe Microsoft should rename the framework
SoundByte.NET because few care to simply explain the facts as they really
are. I've become sensitive to these principles lately.

<%= Clinton


"Karl Seguin [MVP]" <karl REMOVE @ REMOVE openmymind REMOVEMETOO . ANDME
net> wrote in message news:[email protected]...

 

[Ken Ross]

So, if I'm to summarize, you're saying that in reality each language
supports [some] features unique to the language that may provide a
performance benefit for a specific situation. Therefore, there *can* be a
performance advantage to C# if you happen to need the C#-specific feature
OR there may be a performance benefit to VB if you need one of *its* VB-
specific features.

Put another way, there is NO correct choice of language - no "fastest" or
"best" - it all depends on the code you're writing at the time. Taken one
small step further, what you really appear to be arguing for is the use
of both ("all") languages so that you can take advantage of each
language's strengths at the appropriate time.

Interestingly enough, that's exactly what is at the core of the .net
architecture running on the CLR; use whatever language you like,
interchangeably, even within the same application, so you can benefit
from each language's feature set. That holds true for more than just C#
and VB though - if you thought that a particular part of your application
could be coded more efficiently in Iron Python or J#, you can mix those
in as well, and rest comfortably knowing that those classes can be easily
used by every other language.

I think that sums things up fairly accurately.

I don't really agree with your "C# is better because it's like
JavaScript" opinion but that's really a different discussion; for me,
they're not *enough* the same and so working with languages that are
*similar* actually tends to add to the confusion when I reflexively try
to use a C# feature in JavaScript or vise-versa. Working in VB on the
back end and JavaScript on the front is a clean separation - works better
for me anyway.

Ken