This post is intended to give the Java experts out there an overview of .NET technologies and how they compare to what we’re accustomed to in Java-land.
Attitudes
This is an interesting one. Microsofty blogs and whitepapers are inconsistent on their recommendations for architectures, as are the readers of these blogs. In one of the MVC blogs linked below, a couple of people replied criticizing Microsoft for providing tools that lead to overarchitecting! Frankly, I think this comes from a step that Microsoft is taking. Formerly, their tools were good for getting small, non-critical applications written quickly (typical RAD). Over the last couple of years, they’ve begun delivering tools and guidance that’s more appropriate to critical enterprise applications that will have to live and evolve over a period of years. This has led to people who need a Chevy, exposed to 18-wheelers for the first time, wondering why they need all that to get to the grocery store.
Another interesting attitude in .NET-land is a confusion of ‘model’ with ‘picture’. Their current advice deprecates UML modeling in favor of creating UML pictures in Visio. Some of this, I believe, is lack of experience using true modeling tools in their thought-support role, particularly in large, mission-critical projects. While I’m not personally in favor of attempting to create models that replicate every detail of an implementation (A. that’s not a ‘model’. B. it won’t be maintained. C…), I do see a great deal of value in modeling tools to support visualization of what every competent developer already does, in an environment where those visualization can be shared and leveraged to help get the whole team on the same page.
Web Application frameworks and techniques
Generalities
The biggest thing that I’ve had to get used to is that .NET assumes that the average developer is not capable of consistently writing thread-safe code. Because of this core assumption, any object intended to be used in a web application is instantiated for every request.
ASP.NET basics
This would be the canonical application framework for .NET web apps. The closest analogy in the Java world would be JSF. As in JSF, the developer can associate handler methods with various events on any widget on the web page. Unlike JSF, the view’s object graph is built more at compile time than at run time. This, combined with the fact that .NET developers are accustomed to having their world instantiated for every request, alleviates a lot of the performance concerns that have kept us away from JSF. Naturally, another advantage over JSF is that the tool support (really, the reason JSF was structured the way it was) actually exists.
Monorail
Yes, that’s an open source framework inspired by Ruby on Rails.http://www.castleproject.org/monorail/
ASP.NET new direction - MVC
Microsoft developer/architect Scott Guthrie has posted a series of articles to his blog describing a new MVC framework that is now available as an add-on to Studio 2008. From what I can see, this is a fairly sensible framework and reminds me of a better-documented SwingMVC.
Data access
Traditional crap…, err CRUD
The traditional method for Microsoft developers is the typical RAD technique of binding UI widgets to columns in tables. ASP.NET does provide the possibility of a bit of decoupling there - DataSet can be backended by XML as well as direct database access (in fact it’s organized via an xsd by default). However, this doesn’t really do a lot for real type-safety, and it’s pretty weak for separation of concerns.
NHibernate
Hibernate has been ported to .NET with substantially the same functionality. Problems with this in a .NET shop include the usual FUD concerns around generating SQL in general, as well as the usual concerns around open source, and also those produced by Microsoft’s recent/upcoming tools.
‘LINQ to SQL’
LINQ to SQL is a recently released technology from Microsoft that supports ROM (that’s Relational-Object mapping). There is, naturally, a graphical tool to support creating the .dbml file that is then used to generate the entity classes and a DataContext class (think Hibernate session, extended to provide typesafe query access for the specific entities in a domain). The graphical tool, however, is pretty useless except in the case where you’re wrapping existing tables (hence ‘ROM’). If you’re creating new stuff and you want to design your object model and generate the database from that, you’re better off typing the XML by hand. In my current toy project, I’m using the GUI tool to lay out the broad structures and a text editor to get the details right.
As you might expect, I’m also not too fond of the tool’s need to generate the code. You can add manually coded methods to the generated classes, by virtue of the .NET partial class concept, but really, why can’t it just map existing classes to existing tables?
If truly manually mapping, you can simply use attributes on your own classes, as in Hibernate with Annotations/JPA.
Here’s another ScottGu blog (4 parts)
A summary: this thing does most of what hibernate does, except not on POCOs, not as elegantly, and I can’t fix it when it breaks.
ADO.NET Entity Framework
Found here, another ROM framework! This one is more complex, and seems to want you to provide 3 xml files: ‘conceptual schema’, ’storage schema’, and a mapping specification. Why it needs the two schemas in XML, when they already (should be) in their respective domains (object and RDB) I’m not too certain. Once again, it generates the entity classes. Why did they make it this hard?
I’ve not played with this at all at this point, so I don’t have any concrete comments.