On 8/18/06, Magnus Hagander <mha@sollentuna.net> wrote:
> > the .net 'way' of database application development is to keep all
> > the logic in the .net middleware. please note that I am completely
> > opposed to this because it obfuscates good data management
> > practices.
> > however based on the op's comments I am guessing he is doing things
> > the .net way.
>
> Not really. It's one of the ways. Another way that's pushed pretty hard
> with .Net is sticking your logic in stored procedures. The .Net tools
> from MS integrate very well with situations where all your logic is in
> stored procedures - both in SQL Server 7.0/2000 (which has only TSQL
> stored procs) and 2005 (which has TSQL and also CLR/.Net language
> independent stored procedures).
>
> The tools let you do it either way. Unfortunately a lot of people don't
> realize the gains to be had by choosing the right one.
yes. in fact, iirc the ms team blew out the java pet shop performance
demo by making use of stored procedures on the database. the .net
stack can be used to make excellent database applications if used
properly. however, most if not all the .net developers I have worked
with professionaly (with exceptions from the asp.net world) are vb6
expatriates who do thick client designs. visual studio very much
encourages this as does the entire ado.net stack which is my least
favorite part of .net...imo its over designed and a solution in search
of a problem.
2005 yukon is actually a nice database, second in my opinion to only
postgresql in overall capabilities and general design. you can't deny
though that ms encourages development of logic in the middle tier or
'business layer', whatever that means.
merlin