LINQ-to-SQL has been a huge success with the .NET community. While other ORM frameworks such as nHibernate, SubSonic, etc...have been available for years, many Microsoft shops prefer to work with Microsoft offerings when available. For those nHibernate users out there, the visual designer for LINQ-to-SQL is also a welcome feature in Visual Studio--no more XML files to edit.

As most already know, LINQ-to-SQL is only for use with SQL Server and for projects with a near 1:1 relationship between the database schema and domain model. What if you want to use Oracle? What if your domain model differs from the underlying relational structure? LINQ-to-Entities addresses these concerns.

LINQ-to-Entities is the next major addition to ADO.NET, and it provides a much fuller feature set than LINQ-to-SQL such as:

• Domain Modeling Capabilities and the ability to define conceptual, data store agnostic models
• Object Relational Mapping Capabilities (full CRUD and state management scenarios)
• Database independent Query Capabilities using LINQ or Entity SQL

The ability to work with a conceptual model versus a relational model is really the highlight of LINQ-to-Entities. For an in depth comparison of LINQ-to-SQL and LINQ-to-Entities, check out this pre-release documentation on MSDN.

If you are like me, you've been developing in ASP.NET since the beginning, and you truly enjoy the development experience. Like many other .NET developers, I had some experience with VB and Classic ASP before I moved to .NET. At the time, the Page Controller model was a familiar friend from the Windows development world. Someone well versed in WinForms development could transition to web work with minimal fuss. In most cases, this still holds true today in the .NET framework.

The PostBack model in ASP.NET does a very good job of shielding the developer from the inner workings of HTTP. This speeds development time for the most part, and it lessens the learning curve for new developers. However, some developers felt that the PostBack model held back too much from the developer. This made other frameworks such as Ruby on Rails more appealing, and thus spawned projects such as Castle Monorail.

The popularity of Rails and the Castle Project (as well as other MVC frameworks) finally caught the attention of Microsoft. Which brings us to ASP.NET MVC. ASP.NET MVC is welcome addition to the .NET world--it provides a true MVC architecture for web applications. Ruby on Rails developers and Monorail developers will both see some similarity in Microsoft's implementation. In fact, Microsoft has left hooks in ASP.NET MVC for Castle Monorail components.

In the end, ASP.NET MVC won't just be a Rails clone, but rather a best of both worlds framework. True MVC architecture with the power and flexibility of ASP.NET server side controls. You can get the latest version ASP.NET MVC here and you can read up on the latest release on Scott Guthrie's blog here.