If you’ve followed the Astoria team blog for the last year (well almost a year), you’ve no doubt noticed the team’s transparency in discussing design decisions. In addition, they were very open to feedback, and in many cases, it was actually customer comments/suggestions that solidified the direction of certain features.
Today, the Entity Framework team has followed suit and started a new blog that will focus on providing the community with a view into their design process for v2. The initial post outlines a list of features being evaluated for inclusion and shows a glimpse into what can be expected with the release. I encourage everyone to take advantage of this resource and voice your opinions on forthcoming design discussions.
Daniel Simmons just posted a great article comparing the Entity Framework to some other available options to .NET developers (ADO.NET, LINQ To SQL, NHibernate). While the entire write-up is really good, I think his concluding sentence sums it up really nicely: “The EF is not just an ORM–it’s the first step in a much larger vision of an entity-aware data platform.”
That’s the point I always try to make clear when speaking with people about the Entity Framework. The EF vs. NHibernate argument doesn’t really make sense because they aren’t 1:1 technologies, and have significantly different goals in the long-term. Is NHibernate a more mature ORM today? Yes, of course it is, because it’s been around a lot longer. Does EF provide a very strong ORM as well as a rich modeling tool that can be leveraged in numerous scenarios and continue to return on it’s investments? Yes, I’d like to think so.
If I decide to adopt the EDM as my application modeling/mapping tool, not only can I begin consuming it in my applications using the EF, but I can then expose it over the web using ADO.NET Data Services, and I can also build on top of it to create an ASP.NET Dynamic Data application (or enhance an existing WebForm application with Dynamic Data behavior). As of the release of .NET 3.5 SP1, you already have three compelling scenarios that leverage your single EDM. Moving forward you can imagine that list of EDM consumers will grow significantly.
Keep in mind that both ADO.NET Data Services and ASP.NET Dynamic Data are not coupled to the Entity Framework, but they provide first-class support for it out of the box, which makes the integration between them very strong. For instance, if using an EDM as the data source for an ADO.NET Data Service, the model has clear definitions as to what each entity type’s key is (where it’s a composite or singluar key) built-in, so you don’t have to do anything extra to instruct the data service. If you’re using any other data source, your entity type’s key properties have to abide by a specific criteria, which could include you having to salt them with a specific attribute.
When I need to get into “the zone” while coding, nothing does the trick better than some uptempo instrumental rock music. It’s inherit ability to motivate is undeniable, and I find it goes a long way towards enhancing creativity as well.
My current drug of choice is a Russian band named Mooncake (how can you not just love that?). I’ve been rocking their latest album this week and I must say it provides the perfect mid-day boost. They play great rock music, but not in the bland/gritty sense. They’re epic but not over the top. They’re catchy but not cheesy. They’re…well, you get the point.
My favorite track by them is “Short Stories of Methuselah Tree” (it pretty much dominates), but the rest of the album holds it own just fine. They’re definitely worth checking out.
Listen
Website
In .NET 3.5 the System.Xml.Linq assembly was introduced, adding a new set of classes for constructing XML, as well as extensions for querying XML using LINQ. The term LINQ To XML was coined and has since referred to both aforementioned tasks. While the name LINQ To XML makes perfect sense for the act of writing a LINQ statement against an XML source, the name has little application for the act of building an XML tree using the new API. For the sake of explicitness, I’d like to see a name that could be given to the group of “X Classes” within the System.Xml.Linq namespace (aka the XSpace) that could eliminate any ambiguity when differentiating between it and the actual use of LINQ To XML.
I was pondering over the name XPI (XML programming interface). It seems to make sense on a few different levels:
- It is indeed a programming interface for XML…
- Every class within the API is prefixed with “X”, hence it isn’t an API but rather an XPI…
- It’s an acronym and we all know that we need more of those…
This probably isn’t the best name in the world, but it certainly has a nice ring to it…
- “So I was out the other night, minding my own business, and all of a sudden this dude gets up in my grill questioning my XPI skills and I was like what?!?!”
- “I knew I liked the girl after she admitted her fixation with 80’s hair metal, but it wasn’t until she told me she was into XPI that I realized I loved her!!!”
- “I’ll take .NET 3.5 XML programming interfaces for 300 hundred Alex” - Contestant
“This XML programming interface was introduced in .NET 3.5 and is pretty freakin sweet.” - Alex
“What is XPI Alex?” - Apparently cool contestant
Need I say more? If you don’t believe me, don’t take my word for it…
When the ASP.NET 3.5 Extensions preview was released back in December, it included the ADO.NET Data Services AJAX client library embedded into the System.Web.Extensions assembly, making it possible to reference by name from a ScriptManager (as shown here). This made it pretty simple to get up and running in order to consume a data service from within your ASP.NET applications.
With the release of .NET 3.5 SP1 beta 1, the ADO.NET Data Services AJAX client library has been pulled out of the System.Web.Extensions assembly and is no longer available out of the box. Luckily, the same JavaScript files that were baked into the ASP.NET 3.5 Extensions release are available on Codeplex and can be downloaded (here) and included in your projects.
Do you feel like consuming a data service from ASP.NET AJAX is a common enough scenario that you’d like to see the ADO.NET Data Service AJAX client library brought back into the framework? Or is having it on Codeplex suitable for those few situations when you might need it?
