Signed up to work for the software empire

Bigyan Rajbhandari — Mon, 16 Jun 2008 15:02:58 GMT

That’s right, I recently took a job offer from Microsoft as a Software Engineer and will be starting there in July. After few months of grueling interview process and tough decision on my part, I decided that it was an opportunity that I couldn’t miss.

So why Microsoft? Well, there are few things. First ‘aspiration’, I have always wanted to work for the software giant, the fact that you have opportunity to impact millions of people by your work is impassable. Second, working with smarter people and chance to learn new things every day is appealing. And rest like benefits, location etc.. are definitely added bonus.

Why NOT Microsoft? Looking from outside in, I have had doubts if I should take the opportunity. Particularly, the way big corporation works and the “red tape” around the processes. And of course there is a big difference between aspiration and reality. Also, I have heard horror stories of people who came out of there. Someone even asked me if “I sold my soul to the evil empire”. And finally, the rainy weather and expensive real estate in Seattle. But in long term, these were trivial compared to the opportunity. And I should not even complain about the rain compared to snowy winters and humid summers here in Des Moines. And being near to Vancouver is a big bonus for my wife and our family.

My job? It’s still .Net development. I’ll be working for Relationship Experience Division at Issaquah location near Seattle. Currently, I only know the high levels of the projects I might be working on; I guess I’ll find out more once I actually start there. Will I still be blogging? Definitely! I have heard MS is encouraging its employees to blog more. Though I probably won’t be able to blog everything, I’ll try to keep it as up to date as possible.

When’s the big move? It’s probably going to be July 1st and its coming up pretty fast. Though it’s nice that they will be taking care of everything for the move, I still need to kind of plan for it on my side. And moving from one place to another is definitely not easy. Still need to tie all loose ends at my current work, move and settle in Seattle area in 1 week, enjoy a vacation the following week and then start the grind on Monday!

Best practice and effective way of using DataContext in Linq to SQL?

Bigyan Rajbhandari — Wed, 19 Mar 2008 01:51:33 GMT

NOTE: See my follow up post here for more info.

At work, Jeff and I have been throwing around ideas to find a best way to implement DataContext in Linq so that we can integrate it into the base class in our framework while achieving following goals.

Implementation should be easy and non-redundant, so that we do not need to do new DataContext(), every time we have to use one.
Portability of the DataContext should be such that we do not need to pass it around as parameters from one tier to another.
"Unit of work" pattern should be well represented and "very" transparent.
Context should not be persisted without intent, or be open to manipulation from other methods, such that "unit of work" is compromised or a transaction is ill-represented

These seem like simple goals given the features and flexibility of LINQ, however, in reality this has become much more difficult and annoying to achieve than we previously thought. Here are several ideas we have been kicking around, and problem it presents. I would like to hear from people who have effectively used LINQ Datacontext in these scenarios or in a pattern that's most effective.

1. Creating and disposing LINQ as required.

DbDataContext myContext = new DbDataContext();

//your code goes here

myContext.SubmitChanges();

Problems with this pattern:

Creating datacontext everytime we need to use is cumbersome and in my opinion just verbose.
If you have to use datacontext in any of the method this code calls, you'll have to pass the datacontext with it. This is one- too many parameters to pass around

2. Creating a static DataContext and using it throughout the application.

DataLayer.DataContext.Current

Problems with this pattern:

Creating static object isn't always a good thing. In this case, the context is available for manipulation at any level. And unit of work quickly becomes very hard to maintain
If manipulated by other threads or methods context isn't clean anymore and cannot be trusted

3. Ambient DataContext (Currently using this)

The idea behind ambient datacontext is that context is created for a particular thread or a httpcontext(in asp.net) as soon as there is a first call for the DataContext. Then the same context is used for that thread or request unless it is disposed manually. This is done by storing the context in the request/thread data store. The approach to this pattern is similar to static DataContext, however, separation is provided for each thread and requests. This works really well in Asp.Net, however, is again plagued by some of the problems of static context.

Problems with this pattern:

The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
Portability across thread is very hard
Unit of work pattern is not transparent enough

4. Finally, the last idea we've been trying to come up with is concept similar to TransactionScope.

In this pattern, you would used using{ } block to initialize your context and represent a "Datacontext Scope". Any method below that will automatically be able to figure out the proper context, through thread/request datastore. Then just before the dispose happens, you manually call the SubmitChanges() method. This is the one I like so far, however, has few practical problems.

Problems with this pattern:

If sub method needs to implement a new context, we need to figure out how to exclude it from the parent context's using block. If allowing multiple contexts in multiple using blocks, how do you determine which context to use in sub-sub methods?

Please do comment on what you think is the best approach to solving this problem.

Software Development

Signed up to work for the software empire

Best practice and effective way of using DataContext in Linq to SQL?