On 8/18/06, Magnus Hagander <mha@xxxxxxxxxxxxxx> 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
