In my previous couple posts, I have been religiously trying to solve the problem or should I say 'find a best pattern' to use with linq to sql. In past few projects, I ventured into Linq to sql world abandoning ORM tools (OR mapper, NHibernate…) that I had been using; however, I have been greatly disappointed by the fact that Linq to sql doesn't support few fundamental concepts/patterns (LINQ to SQL takes a little different approach than traditional ORM tools). I am starting to have serious doubts if V1 of Linq2SQl is even cut out for any n-tier application (I am not even thinking enterprise application). Don't get me wrong, LINQ is a great framework and LINQ to SQL is an awesome extension. But in the real world business application the implementation of LINQ to SQL out of the box is not practical. How did I arrive to this conclusion? Here's how:
The two fundamental problems it fails to support out of the box are:
Click here to read more...
NOTE: 3/24/2008 - The problem of working with LINQ to sql extends beyond lifetime management of DataContext, thus I am scrapping the second part of my blog. Only thing useful in this post is the performance comparision. Here's new post on LINQ to SQL
In my previous post, I had probed a question on how to effectively incorporate DataContext in ones pattern so the ease of use and unit of work is well represented. Thanks to everyone who provided feedback, it definitely was a good read and provided lots of insight. Few reasons we got into asking this question instead of using simple create/dispose model, in the first place was
- We wanted to make it so that it was easy to use
- We heavily use Repository Pattern for business logic/transaction scoping and Entity model for CRUD operations, so wanted to make sure datacontext we used was as efficient as possible.
- Concerns regarding efficiency of creating/disposing datacontext and not being able to use caching of datacontext effectively.
Click here to read more...
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 quickly becomes very hard to maintain unit of work - If manipulated by other threads or methods context isn’t clean anymore and cannot be trusted
3. Ambient DataContext – The idea behind ambient datacontext is that context is created for a particular thread or a request (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:
Click here to read more...
As a .net programmer at some point in your life, you probably have gotten into a discussion or at least faced a choice between VB.net and C#.net. Though the argument is never ending on both sides, how do programmer that are bilingual or someone who is just learning feel? What long term productivity impact does this have in development shop or team in general?
Well for me, I clearly have choice in mind, but instead of presenting my views today, I will publish the following list our good friend Jeff Lanning compiled from various sources few years back. Though some of the points have changed with new version of .Net, I hope it provides a good reference for anyone dealing with such a choice. Here it goes; don’t forget to put in your two cents:
Reasons to Choose C# over VB.NET:
C# was designed expressly for the .NET platform and Microsoft is standardizing their company on it, which means they have a much deeper investment in C# technologies (language features, compilers, dev tools, etc) than they do in VB.NET. In fact, both Visual Studio and the .NET Framework where written in C# (using C++ as a backend). Furthermore, C# was submitted to, and standardized by, the ECMA group as an open standard while VB remains proprietary.
The C# language is very similar to the other major languages (like Java, JavaScript, C/C++, PHP, and Perl) and shares many of the same concepts, keywords, and syntactical elements. These similarities means a C# programmer will be more able to read...
Click here to read more...
It’s no secret that Microsoft’s is releasing the source for some of its core .Net classes in upcoming visual studio 2008. Before that arrives, the option to look at some of core classes is probably the .Net Reflector. Every now and then, when I want to find out how Microsoft implemented some of the functionalities in core classes, or if I want to learn better way to program, I use the reflector to dig through the core components. During these adventures, I have bumped into various classes and functions, that I thought were just too cool, and also unfortunate that most were internal only. One of my favorites is the VirtualPath class. However, during this quest I have also found that in some way or other the framework team did expose some great utility functions. Most developers aren’t aware of this, including myself and make the mistake of rewriting it. Thus, here’s a shot at exposing some of the cool Utility Classes and Functions (I have been using) that every .Net developer should know. (I hope to keep adding to this list, if anyone has other suggestions please feel free to add.)
Read More
As a developer it’s pretty interesting the type of things you run into. Well, couple weeks ago at work, I ran into a situation where I had to reverse engineer the webservice from php, however, still had to maintain the .php extension on the endpoint. In asp.net this is pretty easy to handle using handlers and build providers. Here’s how you can configure your asp.net so that it builds your .php file as if it were .asmx/.aspx.
1. First of all, you’ll need to configure your IIS to handle requests to .php (.cfm/.jsp etc…) with aspnet_isapi. Browse to your virtual directory ->properties->Configuration->Add extension mapping. Configure it as show in the picture.
Read More Here
More Posts