posted on Sunday, February 22, 2004 10:03 PM by stefandemetz

Why .NET developers don't grok advanced stuff

Picking up on Sam Gentile's post I completely agree that there are not many developers understanding the advanced features of .NET like Remoting, transactions, queuing, LDAP and encryption stuff. Java folks do much better being accustomed to products from enterprise vendors like SAP, IBM, Oracle.

By comparing these thesis with my own experience doing gigs in many places I put it down on 3 things:

1) DNA
Many .NET developers come from a line of business environment, web design or client server world where most programming is pretty simple as the code then resides on one or two layers , does things like validation and some data access.
 
2) Vendor education
Most articles focus on doing the simple stuff or how to do things like a datagrid pretty.

3) Toolsets
VS.NET for all it's cosiness is targeted at beginner/intermediate developer, helping with things like data access and doing simple stuff simpler. Enterprise templates are inside, just pretty well hidden.
Architectural guiding or enforcements is non-existant. The wizards to facilitate writing microcode are ok, but where are the wizards for doing the advanced stuff like Remoting, transactions, queuing, LDAP and encryption?


Anecdote: Before joining the .NET world I worked on the Oracle JDeveloper IDE. Jdeveloper allows you create queues with routing and all from DB tables or objects with a wizard generating stubs both inbound and outbound. And then
routing and stuff, all graphically like designing a DTS package in SQL Server. Where's a thing like that in VS.NET? (perhaps White Horse modelling will do that !!??)


On the architectural side, VS.NET doesn't really help for large projects unless the (experienced) developers creates the layers as projects himself. VS.NET should create the 3 or 4 layers automatically as new projects or slice in different namespaces as WebForm1.BLL.cs, WebForm1.DAL.cs,WebForm1.UI.cs in one project and then nag the user if the architecturally wrong classes(like ADO.NET) are placed in the presentation layer.

Original post
http://samgentile.com/blog/archive/2004/02/12/11304.aspx
Others
http://udidahan.weblogs.us/archives/015193.html
http://weblogs.asp.net/cosgood/archive/2003/04/23/5994.aspx
http://staff.develop.com/halloway/weblog/2003/01/23.html
http://blogs.geekdojo.net/pdbartlett/archive/2004/02/12/1007.aspx

Rebuttal

http://blogs.msdn.com/alowe/archive/2004/02/24/78878.aspx


 

Comments