Another article on DotNetSlackers discussing LINQ-to-SQL objects and how to cache them and reuse them across different DataContext objects.
Read the full story here.

http://dotnetslackers.com/articles/csharp/ObjectsAndStateTrackingInLINQToSQL.aspx

Silverlight 2 does support threads through much of the same API as the big .NET FX. So you use classes in System.Threading such as Thread and ThreadPool. Or you can use the higher-level BackgroundWorker type from System.ComponentModel. This is anyway the recommended approach. 

private void btnWorker_Click(object sender, RoutedEventArgs e)
{
  _bkgndWorker = new BackgroundWorker();
  _bkgndWorker.DoWork += new DoWorkEventHandler(_bkgndWorker_DoWork);
  _bkgndWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(_bkgndWorker_RunWorkerCompleted);
  _bkgndWorker.ProgressChanged += new ProgressChangedEventHandler(_bkgndWorker_ProgressChanged);
  _bkgndWorker.WorkerReportsProgress = true;
  _bkgndWorker.WorkerSupportsCancellation = true;
  _bkgndWorker.RunWorkerAsync(10000);
}

From the various event handlers, you can freely access any UI elements because the class magic makes your code run within the UI thread. In .NET FX, when you use plain threads, or the thread pool, you can't directly access UI elements because of thread is different from the UI thread and the UI elements are not thread-safe.

Silverlight 2.0 offers a facility to cross the thread boundaries and reach directly the UI thread. It's not magic or a different runtime. It's simply a facility to make your coding easier. Here's how it works.

private void btnThread_Click(object sender, RoutedEventArgs e)
{
  ThreadStart code = new ThreadStart(DoSomething);
  Thread t = new Thread(code);
  t.Start();
}

private void DoSomething()
{
  Thread.Sleep(5000);
  this.Dispatcher.BeginInvoke( delegate {
     lblThreadOutput.Text = "Updated from a background, non-UI thread.";
  });
}

The Dispatcher property on the UserControl class does the trick. It refers to a System.Windows.Threading.Dispatcher object that offers a BeginInvoke method through which you specify the code that it has to dispatch to the right UI thread. You pass BeginInvoke either an anonymous delegate or a function pointer. Nice and effective. One of those things that Silverlight does better than the big .NET FX.

Coming to Dublin in just a few weeks (May 27) for a full day of public, 9-to-5, LINQ, LINQ-to-SQL from ASP.NET and Silverlight. Read all details here.

A pattern-oriented look at LINQ and LINQ-to-SQL from within Web and Silverlight applications

We'll start the day with a 10,000 look at LINQ. Hey, I can hear some of you complaining that it is just the "usual" boring stuff about LINQ being so cool etc. Things that you've probably heard a zillion times. Well, sort of. As Don Box told me once, it's all about perspective. So in the first module you'll hardly find me discussing how to group/join data. I'll focus on the architectural model and drive you naturally to understand the various flavors of LINQ. A full understanding of the IQueryable interface will open up a new perspective on LINQ-to-SQL and LINQ-to-Entities. 

In the end, LINQ-to-SQL is two-folded. On one end, it is a programming tool for a DAL, but if you know it well it can morph into a simplified, but not less effective, O/RM tool.

After due lunch, discussing data access strategies from ASP.NET and Silverlight with patterns. Which patterns? MVP and MVVM. And services. And data feeds.

It'll be fun. Don't hesitate to ask more information :)

Recession is perhaps affecting the economy, but it couldn't be farther from the dazzling world of (Microsoft) software. CTPs are coming out every day and some of them are amazingly morphing into Betas. Which is anyway good. But when a technology turns of age becoming a Beta, you--the developer|architect|software engineer--are no longer authorized to ignore it with the abused excuse that it is only a CTP.

You can easily be flooded with technologies, frameworks, products, and also patterns and paradigms. This is especially true for the Web. Isn't AJAX representative of a "paradigm shift"? Paradigm shifts, though, are an extremely delicate event that occurred in the history of mankind quite a few times already. As emphatic as it may sound, the Web of today is just a special case. Search for "paradigm shift" on Wikipedia (http://en.wikipedia.org/wiki/Paradigm_shift). At some point, you'll read:

Paradigm shifts tend to be most dramatic in sciences that appear to be stable and mature, as in physics at the end of the 19th century. At that time, physics seemed to be a discipline filling in the last few details of a largely worked-out system. In 1900, Lord Kelvin famously stated, "There is nothing new to be discovered in physics now. All that remains is more and more precise measurement." Five years later, Albert Einstein published his paper on special relativity, which challenged the very simple set of rules laid down by Newtonian mechanics, which had been used to describe force and motion for over three hundred years. In this case, the new paradigm reduces the old to a special case (Newtonian mechanics is an excellent approximation for speeds that are slow compared to the speed of light).

The Web is a science that before AJAX appeared stable and mature. AJAX is comparable to Einstein's relativity. It will take years to reach again some technological stability for the Web. Read, some set of frameworks and products that are widely accepted and not put under discussion every week by new CTPs and approaches.

Five years? Well, five years may be nothing compared to the mankind lifespan, but it's a lot of time in software, and for the Web in particular. Five years in software are more or less the equivalent of million years of earth life. And even more if you limit to consider the Web, which is only 20 years old.

AJAX has been a real paradigm shift whose effects--three years after its introduction--are only now starting to become stabler. I have a lot of hopes and expectation from MS and the ASP.NET team in sight of ASP.NET 4.0. I expect it to be built with AJAX in mind from the grounds up, incorporating common Web and AJAX patterns in a brand new set of controls and components.

Oh yes, but I started this post with the concept of "driving force" in mind. How can you find orientation in a world full of CTPs? Like many of you, I can't just keep up with everything that is coming out. So I find it useful to identify the "driving force" of each new thing from Microsoft and see whether it cares me to a decent extent. Today here at DevConnections, Orlando, I finally identified the driving force of a buzzword that hit me recently.

ADO.NET Data Services (aka, Astoria)

Driving force: the need of building richly interactive Web systems.
What's that in abstract: New set of tools for building a middle-tier or, better yet, the service layer on top of a middle-tier in any sort of application, including enterprise class applications.
What's that in concrete: provides you with URLs to invoke from hyperlinks to bring data down to the client. Better for scenarios where a client needs a direct|partially filtered access to data. Not ideal for querying data from IE, but ideal for building a new generation of Web controls that breath AJAX. And just that.

I'm going to apply the "Driving force" pattern to virtually any CTP or buzzword that I happen to hear about. Next one is M-V-VM pattern for WPF (and Silverlight). And next, of course, the ASP.NET MVC FX. Stay tuned.

OK, it's not a problem to admit that I have no copyright on it, but I just love to use it.

It looks like a O/RM, it walks like a O/RM, it quacks like a O/RM. Hence, it's O/RM...

What am I talking about? Just, guess what, LINQ-to-SQL.

It's not a full O/RM like NHibernate, Genome, or others. Oh sure, not like EF too :) But it looks like that. And if you're open-minded enough, it also may walk and quack like a O/RM. If this is an acceptable statement for you--it mostly depends on what your definition of an O/RM be--then this might be a pleasant reading: my latest article on DotNetSlackers.

Enjoy and let me hear your thoughts!

A comment from Bigyan to my DataContext article on DotNetSlackers yesterday made me think that I probably had to put my thoughts down a little more explicitly. The question that Bigyan poses is expressed in detail in this post of his and revolves around the best way of dealing with DataContext in multi-tier apps. My experience suggests that you use a new instance of the DataContext for each unit-of-work you need. The DataContext is a lightweight object to instantiate/dispose just for this. Can't find the link but somewhere on MSDN I've found a note (documentation) along the following, quite explicit, guidelines:

In general, a DataContext instance is designed to last for one unit of work however your application defines that term.

It is not recommended to maintain a DataContext live for more such as stored in a singleton object. Likewise, you don't have to pass it around, because it is not exactly a light object once in use with data attached: data + tracking info + mapping info. If you find it cumbersome to write new DataContext at each step, you can use a bit of abstraction and perhaps a Repository pattern. One more thought about not passing it around tiers and layers. You don't reuse the data context; you'll reuse the data you attach to it. So it makes sense to cache data somewhere and using distinct data context to do manipulation. On the new data context, you just attach any desired data. Yes, again, using the DataContext should be kind of using an ADO.NET connection: you use always new DbConnection objects but reuse command text and parameters. You never keep a connection open for a long time and don't pass it around tiers.

My two (euro)cents.

An article on the internal structure of the DataContext object of LINQ-to-SQL is out on DotNetSlackers. Enjoy.

I love the VS embedded Web server, but it too often makes you thinking that things are easier than in the real and bitter world. So a trivial Silverlight 2.0 sample page that works from within the auto-generated ASP.NET Web site stops working as you create an IIS application for it. The symptom? No Silverlight content shows up and any network monitor tool you use reports that no XAP resource was found. But the resource is there. It's a simple matter of configuring IIS, though.

I was going to write a post myself. But then I found out that someone already did it. And it's a great write-up.

Silverlight 2 Beta 1 is out and I just installed it on my machines. OK--we're now ready for the next stage. A key question to answer for virtually everybody planning RIA development is:

• Should I go with a Plain New Web approach and opt for AJAX on top of ASP.NET (or whatever else)?
• Should I go with a Silverlight 2 approach in just a few months when it'll be released?

Put down simply, it's a matter of deciding whether you may or may not afford a plug-in of approx 4 MB to be downloaded/installed on client machines. Not an issue for intranet applications and most Web sites. Possibly an issue if you want to maximize (and even more) the audience of your portal. I expect to start seeing on home pages a choice Web|Silverlight in much the same way we see today a choice among languages.

To explore the tools, to refresh the techniques, to learn patterns and models, to grab directions, may I suggest you some hot stuff happening in a warm place this Spring?

If you have a strong interest in sun and beaches in the warm Mediterranian islands, now you can also have some AJAX and Silverlight training in the same package :)

People of Europe (and not just Europe), join us ...

The latest baby, Programming ASP.NET 3.5 Core Reference, is out and you can freely download the full source code (21 MB) from here. It should be noted that for sort legal reasons (sic!), the binaries of the AJAX Control Toolkit couldn't be added to the package. It's therefore up to you to download and install it separately. Then make sure you have the proper DLL in the Bin folder of the book samples application.

Enjoy :)