LINQ

Weekly microsoft oriented crumbs #3

Still more “mesh” related news Microsoft Live Mesh to get more competition — from Sun and Scoble on why Microsoft Live Mesh will fail with early adopters and elsewhere Microsoft’s Oslo connections begin to bud and more interesting Mesh links at Alvin Ashcraft’s post

Daniel Cazzulino looks at Live Mesh FeedSync protocol under the hood and Steve Clayton points to Live Mesh - First Look whitepaper

Vitorrio Bertocci lays out a coarse taxonomy for claim types

Sam Gentile with New and Notable 236, 237 and 238, Part 2 (Identity Management) and Part 3 (Claims Links) of SAML and Federated Identity, and a High Level View of the Neuron ESB Architecture, the WCF and SOA Enabler

Nicholas Allen points to Updates to WCF Security Guidance, Messaging Additions in Orcas, Part 2, Part 3, Part 4
Serialization of private data members, and news that TIBCO Announces WCF Integration

Dominik Baier points to Some Resources for P2P and WCF
J.D. Meier : 6 New patterns & practices WCF Security How Tos

Scott Hanselman’s Computer Zen - The Weekly Source Code 25 - OpenID Edition

Udi links to a video of Messaging and Architecture Discussion at ALT.NET, speaking of which has an interesting post about making Spec# a Priority

April 28th Links: ASP.NET, ASP.NET AJAX, ASP.NET MVC, Silverlight - ScottGu’s Blog

Interoperability Happens - Channel 9 Interview with Yours Ted Neward

Immutability and tail recursion

Props to link blogs
Christopher Steen
Jason Haley
Chris Alcock
Alvin Ashcraft
Arjan Zuidhof

Technorati tags: wcf, soa, architecture, webServices, .net, REST, WCF

Weekly microsoft oriented crumbs #2

Microsoft Says Yes With Mesh - Steve Gilmores take on Live Mesh and a with talks to David Treadwell, VP of the Live Platform Services in his podcast

Robert Scoble with the early scoop Ray Ozzie delivers with Live Mesh

Videos explaining various pieces of the mesh Ori Amiga: Programming the Mesh, FeedSync: Synchronizing the Mesh

Dino Chiesa on Varying Content-Type according to the URL in a WCF REST Service

BizTalk Server 2006 R3 Announced, New and Notable 235 from Sam Gentile also a primer on SAML and Federated Identity

Nicholas Allen on WCF, WF, and BizTalk Sessions at TechEd, and Messaging Additions in Orcas

Books: We need more So What, Now What and What For? and less just What - Scott Hanselman On the type of books we need

Simon guest on Why Architects should care about Robots

An InfoQ Interview with Krzysztof Cwalina on Framework Design Studio

Kirk Allen Evans with a list of useful links on WCF, WCF, ADO.NET SyncServices, and ClickOnce and the second installment of Calling Web Services via AJAX

Community Convergence XLIII - Charlie Calvers Links on LINQ

Matthew Podwysocki with a Recap of Day 2 of the ALT.NET Open Spaces in Seattle

Another fun read from Jeff Atwood “Everything I Needed to Know About Programming I Learned from BASIC“

More fun? check out the video Marc Mercuri and Kyle Johns: Inside RoboChamps and Simon Guest on Why Architects should care about Robots

Props to link blogs
Christopher Steen
Jason Haley
Chris Alcock
Alvin Ashcraft
Arjan Zuidhof

Technorati tags: wcf, soa, architecture, webServices, .net, REST, WCF

LINQ to SQL and the quest for the perfect DataContext “lifetime”

Reading posts like this from Microsoft MVP’s, it’s quite obvious that the best practices around using LINQ to SQL aren’t really evangalized well enough. Siting the post not because it is bad or un-insightful in any way; but just that even Microsoft MVP’s are struggling with how to wrap their heads around how the use the power of LINQ to SQL in a high transaction/availability web applications.

The problem here isnt with LINQ however, but its unfortunately named cousin, LINQ-to-SQL. As one of the commenters points out

The problem stems from the fact Microsoft have effectively merged two design patterns (Unit of work and Data gateway) into a single object - DataContext.

Well that too! The fundamental problem IMHO, is that there is coupling of two concerns namely object/change-tracking, and LINQ provider for SQL server. If it were properly factored/separated so that the facilities like change-tracking could be layered on top LINQ, then building n-tiers applications wouldn’t be the subject of so many posts on the web!! At the very least it wouldn’t be easy to create applications poorly architected for performance and scalability. The Datacontext not very different from DataSets, only packaged disguised and bundled with a LINQ provider to SQL Server.

1. Datasets support change tracking
2. Datasets can can manage relationships of entities within it
3. Both make it easy to create database centric applications the quick and dirty way

Enough ranting! On to my opinion about what the lifetime of the DataContext should be

* For web application, Short and sweet and ignore the change tracking feature
* For a winforms application, i’d say long live DataContext! Can really leverage object tracking and change tracking features

This comment on the same post seemed very interesting

If we have this, of course we could use what it’s called Linq to SQL “POCO Support”, this means that we are not forced to use the auto-generated classes with its EntitySets and EntityRefs, we can use just any plain class with the appropiate attribute decoration.

This allows to create your own disconnected change tracking (there’s no Microsoft solution to this problem in current versions, either in the upcoming Entity Framework)

The commenter has a project at codeplex and it seems an interesting solution

Free book preview for C# 3.0

C# Query Expressions and Supporting Features in C# 3.0

This is a sample of a book that I have been working on with my coauthor Jamie King. As of March 2008, the full book is not yet available. However, this sample covers C# 3.0 fundamentals, and provides a full grounding in C# 3.0 Query Expressions.

It’s become more common for authors to offer a few pages or a chapter of their text to the public as a means of marketing. Our aim is to not only provide a sample, but also a useful stand-alone text. By itself, this sample provides any C# 2.0 programmer a foundation in C# 3.0.

Very in-depth look at query expressions. Book review out by Jon Skeet

Weekly crumbs #5

Microsoft Technologies

Creating JSON-enabled WCF services in .NET 3.5 – an even simpler approach
The entire chapter 2 of “Understanding Windows CardSpace” published on Code Project
A gentle geek introduction to Volta
UserName SupportingToken in WCF

Web 2.0

Building Action Streams [via Dare Obasanjo]

SOA

Relax-WS
Why Big Consulting is Hurting SOA

Misc

Chuck Norris bested by “a lack of talent”

LINQ to SQL first impressions

While creating a windows application using LINQ the first thing that struck me was, yes, this is cool and it makes it looks so easy. This is great for a client-server application! After the initial eye-candy-effect faded I was stuck with a very fundamental question; what is the typical lifetime of the DataContext derived object? Are there any best practices around it? After a little bit of googling heres what I found in the LINQ Project General forum

…As you may notice, DataContext pins entity objects. hiding them from GC. That means, once object was retrieved using DataContext, it’ll be in cache until DataContext is alive. Doesn’t this mean that DataContext has to be short-lived object? Any guidelines/examples of proper using of DataContext would be really appreciated.

And the moderator’s reply

2) Yes, the DataContext should not be long-lived for a server app. You should create one to cover the duration of a transaction. For client code this is less critical.

Which leads me to think that it is not very easy to scale the application with this approach when you apply SOA and split the application into n-tiers; handy as it may be for a connection oriented applications (read: windows application), over HTTP, a protocol thats inherently disconnected, the LINQ-to-SQL model degenerates into a nifty way to query the database without using a third party ORM/ORM-like solution.

Digging further I found a couple of articles that allow you to work around this limitation either by allowing you to “Detach” and “Re-Attach” entities or working around it when they cross tier boundaries. All of these solutions mean that the DataContext has to stay around in memory to track changes and if objects created by it. If the objects are “pinned”, as the forum post suggests, this would mean web applications/services that have session affinity with a potentially large memory footprint which may not really allow the application scale!

I havent looked at what Entity framework has to offer yet, but LINQ to SQL seems very Dataset-like! Disappointing!