Slick-Ticket v2.0 Released

Many improvements across the board, mostly behind the scenes

I am proud to say that I have released version 2 of my open-source trouble-ticketing/help desk system Slick-Ticket. I wasn't initially planning on making a new release, but the program has become suprisingly popular with over 3,000 downloads and an actual (small) community of users which is great!

You can download Slick-Ticket v2.0 if you have never used it before. If you have already been using a previous version, you will need to replace your existing code with the patching program, run it, then download version 2. It does a few database modifications to cleanup the lack of seperation of markup/db which was done very poorly in a rush of the first version. As with any upgrade, I highly recommend you backup prior to running this upgrade!


  • Broke the dbi.cs class up into more discreet classes
  • Renamed many methods properly
  • Removed (non-user-added) markup from any of the database fields
  • Moved some markup from the code-behinid to the .aspx pages
  • Globalized and ready for translation
  • Added ability to possibly delete attachments/comments/tickets in the future
  • Introduced some more dependency injection
  • Code is now much more robust!

FormFields for - New Open Source Project

transform and simplify your markup by allowing inclusion of form validation, uniform display, Linq-to-SQL integration and databinding with minimal effort forms are already simple, there are many tools such as DetailsView, ListView, etc. that can make our lives easier, but sometimes they just won't do. In those cases, we have to resort to writing repititous code for forms, that is what FormFields was developed for. Writing markup over and over for things such as validation, regular expressions, dropdownlist databinding, etc gets old really fast, so I developed a way to simplify it as much as possible.

Take for example a date entry field. You have your TextBox, then the CompareValidator to make sure it's a valid date, then a Mask to limit the user's input, a RequiredFieldValidator to make sure they enter something, a WaterMarkExtender to guide the user and finally a CalendarExtender to make input easier.

Now this is great stuff for a UI, and not too hard to write, but when you have to do more and more entry fields such as SSN, phone number, a dropdown, then a CheckBoxList; building forms can quickly become cumbersome and hard to understand, become incredibly tedious and turn into a ton of markup.

This is the markup required to do everything mentioned above:

<div class="form-field">
    <asp:RequiredFieldValidator ID="rfvSchoolDate" runat="server" ControlToValidate="txtSchoolDate" ErrorMessage="Required" CssClass="right validate" Display="Dynamic" />
    <asp:CompareValidator ID="cvSchoolDate" runat="server" ControlToValidate="txtSchoolDate" ErrorMessage="Invalid Date" CssClass="right validate" Display="Dynamic" Operator="DataTypeCheck" Type="Date" />
    School Date
  <asp:TextBox runat="server" ID="txtSchoolDate" CssClass="full" />
  <ajax:MaskedEditExtender ID="meeSchoolDate" runat="server" Mask="99/99/9999" MaskType="Date" TargetControlID="txtSchoolDate" />
  <ajax:calendarextender runat="server" id="calSchoolDate" TargetControlID="txtSchoolDate" Format="MM/dd/yyyy" PopupPosition="TopLeft" />
  <ajax:TextBoxWatermarkExtender ID="tweSchoolDate" runat="server" TargetControlID="txtSchoolDate" WatermarkCssClass="light full" WatermarkText="mm/dd/yyyy" />

All of that can be replaced with just this:

<formField:textBox ID="tb_SchoolDate" runat="server" Type="Date" Required="True" Title="School Date" />

Yes, it is just that easy. The payout and styling is all inherited from a single class and is easy to customize while making for uniform displays. There are multiple different presets for it including SocialSecurityNumber, Date, ZipCode, and a ton more.

This is not only for TextBox fields, it also works for CheckBox, DropDownList, ListBox, CheckBoxList and RadioButtonList. And it not only formats everything the same and takes care of validation (anything that is not automated can be easily added) but it also takes care of databinding as well. Instead of making a datasource, adding an initial entry, binding it to the data and adding a RequiredFieldValidator, you can simply do this:

<formField:dropDownList ID="ddl" runat="server" Title="Category" L2STableName="categories" Required="True" />

No DataSource needed, it is all taken care of within the control itself (this is using Linq-to-SQL and the defaults).

documentation and download

I just wanted to give a quick overview of what it does, I have it fully documented and have more examples here: and it is available for download from CodePlex. I hope some people get some use out of this and I would love if people would want to jump in and add new features.

stuff I still want it to do

It does not render in the designer, and you can't put them into the toolbox - I do not know how to do this just yet, I would love for someone to jump in and help out on this one!

I am taking a much needed 30 day vacation, so no new posts/updates will be happening for a while, but I will be right back to advancing this project when I get back.

Shout it kick it on

Asp.Net vs php : speed comparison

why is the myth that php is faster than Asp.Net so prevalent? Asp.Net is faster than php, here are the facts

So many times I have heard php pushers claim that php is so much faster than Asp.Net and that Asp.Net is clunky and slow. The most annoying part is that everything I have read (that is not factless opinion), and I mean everything, says that this is wrong; but for some reason, this myth is widely accepted. It has become a religious argument that ignores the facts.

Instead of arguing this point over and over, I decided to put it here so I can simply refer people to it to set them straight. Keep in mind that I wrote strictly php for over 4 years, it is a great and powerful language that I have nothing against. Not to mention you should not choose your development language by speed, but by what works for you (more on that later). This post is not there to pick sides (though I am now Asp.Net biased of course), just to show the facts.

compiled vs interpreted languages

First of all, at the very base of the argument it has to be realized that the two languages are very different. Asp.Net is an optimized and compiled language, meaning code you enter is reduced to a set of machine-specific instructions before being saved as an executable file. Even if you do not explicitly compile your code before you deploy it, it compiles the first time it is run, then after that it runs as compiled code. Php on the other hand is an interpreted language, meaning it is saved as the code your write and run directly from that code. It is widely accepted and proved many times over that Compiled programs generally run faster than interpreted ones because interpreted programs must be reduced to machine instructions at runtime. Here is a quote from Wikipedia that shows just how much faster they can be: "A program translated by a compiler tends to be much faster than an interpreter executing the same program: even a 10:1 ratio is not uncommon. The mixed solution's efficiency is typically somewhere in between."

the numbers

Now that the theory of why it is faster is out of the way, let's get to some cold hard numbers, so we can put this debate to rest.

The following charts and benchmarks are taken from WrenSoft and quite simply show the difference. Please follow the link if you want an in-depth description of the test.

This first graph shows the time taken to generate and display results for a search a small website.

As you can see, the average time for the php site: 0.1500 seconds, the time for Asp.Net: 0.0150 seconds... that is a HUGE difference, the php search takes 10 times as long! The next one does the same with a larger site, and the results are not much different.

Php took an average of 1.0097 seconds while the Asp.Net run took 0.0810 seconds; php took more than 12 times as long to run, the numbers are there.

Now those tests were run with basically the same code translated into different languages, so there isn't much ammunition in the 'it was coded poorly' argument. But, there is still the [valid] argument that the above tests were run on a Windows machine, and since .Net is native to Windows, it was an unfair trial, so now we will look into the statistics running on Linux, so php will have the 'home-field' advantage; not to mention, c# will be running on Mono.

These benchmarks are taken from who has numerous benchmarks for all sorts of languages and is a fantastic resource. For these tests, I am choosing to compare both vs the baseline of 'Clean' so it is easier to compare; here are the results:

As you can see, even on Linux, .Net is faster across the board; often many times faster. The only other tests I can think would be interesting to run is to compare scalability and such; I would be very interested if anyone has benchmarks for such things.

can we finally focus on what matters?

Go ahead and google vs php speed and you will see that almost all of the posts scream that php is faster, but you will not find any links or evidence backing this up. The whole point of this for me is not even really to show that that Asp.Net is faster, I already knew that; it is to possibly help curb the ridiculous assertions that it is faster. It has basically turned into a religious argument, not a fact based one and that is just silly to me. As in many other things, it seems as if enough people yell something long and hard enough, it becomes 'truth' - it simply is not.

Developing in php is fine, a huge number of amazing applications and websites are written in it by much more skilled coders than myself. That said, you shouldn't choose your language on speed, as development preference is much more important; use php if you feel it is a superior language, but don't push bad information. Most importantly focus on what matters: code in what language you can do your best work in, you don't need to justify it to anyone else, prove that it is faster/better or convert anyone else to using you language - you have better things to do.

But... Asp.Net is faster than php. Period.

Shout it kick it on

Extensions for simplifying DropDownList interaction

Extensions for setting the selected value and removing an item from DropDownLists

I love extensions, they make my life so much easier. Simple things that I can do in a coupole lines of code, I now do in even fewer thanks to my almighty extensions. Here are a couple of super simple ones for easy interaction with DropDownLists

setting the selected value

Sometimes it is a pain to set the selected value of a DropDownList, if it is there, it works fine, but if not, it is a pain in the butt. Here is what I use to set mine:

It's just that easy, and if it's not in the ddl, it will work just as well. Here is the extension code:
public static void Set(this DropDownList ddl,
 string findByVal)
{ // attempts to set a DDL to the 'findByVal'
    ddl.SelectedIndex = ddl.Items
    catch { };

removing an item

Once again, we all know the code for this, but an extension makes it easier, and also hanldes it if the item is not there:

And the code:
public static void RemoveItem(this DropDownList ddl, 
 string item)
  try { ddl.Items.Remove(ddl.Items.FindByText(item)); }
  catch { }

Normally I discourage a blank catch{} but in this case, the only error you would be encountering is if the item is not there, so unless you are worried bout that, you should be fine.

Cloning an Entity in Linq-to-Entities

Making a clone of a record and popping it back into the database

There are a lot of reason you may want to do something like this, for me, users wanted to be able to make a copy of a huge record so they would then be able to go in and change a few things rather than make a whole new record which was very time consuming. At first, I though of pulling the item, manually copying each property, and inserting... but this is programming, there must be a better way. So then I thought about Reflection and how I might be able to work with that, but that became a big mess that I never got working prior to being discouraged. Next I hit Google, and an awesome blog had a great post to get me on the right track:

That solution used Serialization to clone the entity, so simple, and so effective. The example they used there was Linq-to-SQL, but it will work for Linq-to-Entities just the same. I modified the code slightly to be used as an extension to basically any type... as this can really clone almost anything you throw at it (I think):
public static T Clone<T>(this T source)
  var dcs = new System.Runtime.Serialization
  using (var ms = new System.IO.MemoryStream())
    dcs.WriteObject(ms, source);
    ms.Seek(0, System.IO.SeekOrigin.Begin);
    return (T)dcs.ReadObject(ms);

That simple little bit of code will now clone *anything* - perfect! Now is just how to push it back into the db, which can be a little confusing. Initially, I tried this, which was intuitive to me:
MyEntities db = new MyEntities();
note n = db.note.First(nt => nt.note_id == some_int); 
note new_n = n.Clone();

But was met with this error:
An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key.

But, after actually thinking about it, that makes sense, since new_n is the same *exact* object as n, I can't really insert it into the DB, it is basically confusing the two. So to get around that, you have to detach the original Entity:
using (MyEntities db = new MyEntities())
  note n = db.note.First(nt => nt.note_id == some_int);
  note new_n = n.Clone();

Closer, but still did not work, I now got the following error:
The object cannot be added to the ObjectStateManager because it already has an EntityKey. Use ObjectContext.Attach to attach an object that has an existing key.

Which also makes sense as you can't insert an Entity that already has an EntityKey. So one final change and we have a working clone:
using (MyEntities db = new MyEntities())
  note n = db.note.First(nt => nt.note_id == some_int);
  note new_n = n.Clone();
  new_n.EntityKey = null;
  // make any other changes you want on your clone here

And no we have successfully cloned a record (Entity) and put a copy into the database. This would work very similarly for Linq-to-SQL, but I have not implemented it quite yet.

Universal IQueryable Search Version 2 with Reflection

'google-like' search with an IQueryable made even simpler

A little bit ago, I came out with this post: Universal IQueryable Search Usable by Linq-to-SQL and Linq-to-Entities and it worked great, but it got me thinking: if I could implement Reflection, it could be even easier to use and require less code to run as it would get the property names/types automatically. So here I am with the new version and it is working great, it has already saved me lots of time. All of the old overloads work as they did previously, I have just added some more. Here is how a few of them work:

single-level search

Now that reflection is being used, you can pass any sorts of objects to the search and it will only compare like-types, no need to specify. If you are trying to search a collection of 'car' objects in an IQueryable named 'cars' you can just do something like this:

Search(object[] keywords)
var results = cars.Search(new object[] {"chevy", 2007});

That will run through all of the properties of 'car', and if any of them are string variables, they will get compared against "chevy" and if they are Int32 variables, they will get compared against 2007. So this search would pull out all 2007 models made by Chevy.

search for specific properties

The above search will search all the properties of an object, but what if 'car' has 100 properties, and you only want to search 2, that is simple as well with this overload:

Search(string[] properties_to_search, object[] keywords)
var results = cars.Search(
  new string[] {"make", "year"},
  new object[] {"chevy", 2007});

Which will only search the properties 'make' and 'year' for the objects; only comparing like Types.

multi-level search

Now let's say that the object 'car' has a some objects that you want to dig into as properties. The 'car' object has an 'engine' property, but if we run the searches above, it will not drill down into the 'engine' object (though it would compare it if you sent an 'engine' as part of the search array). To get it to drill into the engine object, we need to add another parameter, the Type[] types_to_explore so the Search knows to drill down into objects of that type:

Search(object[] keywords, Type[] types_to_explore)
var results = cars.Search(
  new object[] {"V8"}, new Type[] { typeof(engine) });

Now the Search will search anything in the 'car' object and/or in the 'engine' since it now knows to look inside of it; not to mention it will recursively search down into the objects. This would even find something nested like this:

Since you told it to explore all 'engine' types. This would work even if you wanted to search into string, Int32, bool, etc. Types as they all have lots of properties in the world of Reflection - could be a whole new use for this extension?

multi-level search on limited properties

Basically combine what was covered above:

Search(string[] types_to_explore, object[] keywords, Type[] types_to_explore)
var results = cars.Search(
  new string[] {"engine", "style"}, new object[] {"V8"}, new Type[] { typeof(engine) });

I like this one the least as you have to be most verbose (but not as verbose as the other overloads). If you simply try to search for 'style' here, it will not be found, because you did not tell it to search 'engine' (the property, not the type).

so that's the latest

If you haven't looked at the last post, I highly recommend you do, as it is still the most detailed search overloads are explained there (though a bit tougher to use). This is very hard to explain, so I hope you just take a look at the code yourself or better yet, just try it out, you can see with trial and error how it works better than I can explain in a wordy blog. As always, I am very interested in feedback and improvements!
Shout it kick it on

Automatically refresh your user's Session behind the scenes using jQuery and Asp.Net

Incredibly simple script will keep your user's Session alive without any worries

Now this is something that may or may not be useful to a lot of people, depending on you situation, you may want the user to elect to refresh their Session or not (like banks usually do); but this is for applications that may have a lot of idle time and users are annoyed with their Sessions dying... considering most users don't know what a Session is, but they know that the application stops working correctly.

It uses jQuery and is incredibly simple, just a few lines of code, and no screen flicker or any annoyance to the user at all; ignorance is bliss. First I include the following in the code-behind in any page you need to keep refreshed (works on masterpages as well):

protected int timeout;
protected void Page_Load(object sender, EventArgs e)
    // one minute prior to timeout (milliseconds)
    timeout = (Session.Timeout * 60000) - 60000; 

Then add this jQuery to your script:

aspx or master
var to;
$().ready(function() {
  to = setTimeout("TimedOut()", <%= timeout %> );
function TimedOut() {
  $.post( "refresh_session.aspx", null,
    function(data) { 
      if(data == "success") {
        to = setTimeout("TimedOut()", <%= timeout %>);
      else { $("#timeout").slideDown('fast'); }

Notice that the jQuery calls the $.post() function, where it calls the page refresh_session.aspx. That page does only one thing: Response.Write("success"); so if data comes back and it does not equal 'success' (something went wrong) it then stops the cycle of checking for timeout and shows my 'timeout' div that tells the user it is not a current session.

infinitely refreshing session...

Yup, it is just that easy. The code-behind gets the Session.Timeout, and subtracts one minute from it, this is when the refresh will be triggered. Inside the script, the setTimeout() call will then wait that amount of time and use the jQuery $.post() to hit the page in in turn refresh the Session; once that is done, it starts the cycle over again, so it should repeat on into infinite. And since this is all done via a jQuery ajax call, there is no evidence to the user this is even happening, no flicker or popup, nothing.

Universal IQueryable Search Usable by Linq-to-SQL and Linq-to-Entities

ever since Linq came out, I have been improving my simple 'google-like' searches; I think I found the holy grail

UPDATE 05/12/2009 - I have done a ton of updates to the class using Reflection, and a new version which is much more usable and simple will be out in the next day or two.

The 'quick search' is a great tool. Google has shown us that searching with one single, universal search field is the way that people prefer to search. Anyone who has worked with Linq for any amount of time knows this is possible, but it requires a lot of hard-coding and a long jumble of 'where' statements. This class will allow you to run a universal 'google-like' search on any IQueryable.

Now what I am going to show you here was a breakthrough to me, and it has made my life a whole lot easier. It may not be the best way to do this, but it is the best/fastest way I could figure out (hint: I am always looking for improvements), and it is totally portable for *any* multi-column IQueryable collection, plus it does multiple relations as well!

dynamic linq

First of all, this uses the System.Linq.Dynamic dll that was released a while back - it writes a dynamic query each search run, so this was necessary in my approach. If you do not have it, you can get it here:

data for the example

For this example, I am going to be working with Linq-to-SQL, but this works just as well with Linq-to-Entities and have used it in both types of projects. Here is the dummy data I am using for the demo:
CREATE TABLE dbo.category (
category_name VARCHAR(MAX)

INSERT INTO dbo.category VALUES ('ninja');
INSERT INTO dbo.category VALUES ('pirate');
INSERT INTO dbo.category VALUES ('zombie');
INSERT INTO dbo.category VALUES ('weakling');

CREATE TABLE dbo._user (
first_name VARCHAR(MAX),
last_name VARCHAR(MAX),
email_address VARCHAR(MAX),
category_id INT REFERENCES category(category_id)

  ('stan', 'naspinski', '', 2);
  ('sara', 'ortbals', '', 1);
  ('rj', 'russell', '', 4);
  ('brian', 'pond', '', 4);
  ('idaho', 'edokpayi', '', 1);
  ('phil', 'robles', '', 3);
  ('jose', 'meza', 
    '', 2);

Just a table of users with a referenced table of categories so I can demonstrate the multi-level search. Here is what my dbml looks like:

quick example

Now, say I want to do a universal search in all the fields for the word 'stan', it is as simple as this:
string[] columns_to_search = {"first_name", "last_name", "email_address", "category.category_name"};
string[] search_terms = {"stan"};
var search_results = new dbDataContext()._users.Search(columns_to_search, search_terms); 

All I did was specify which columns to include in the search, and what terms to search for; doesn't get much simpler than that. This is the simplest approach/overload, so you can get much more detailed if you want, and I will get into that later, but here you can see how powerful and simple this is. Here are the results when bound to a GridView:

search for 'stan'
search for 'stan'

This simply runs through the columns you specify and runs a Contains() against each field; if the keyword is found in one of those fields, it is considered to be a valid record. As you can see, the email address of of record 7 has the word 'stan' in it as well as the name and email address of record 1. Now if I narrow the search by adding another search term: 'pirate' you will see it narrows down the search to just one:

search for {'stan', 'pirate'}
search for 'stan', 'pirate'

Now you can not see 'pirate' in this GridView as it is just an auto-generated GridView, but 'pirate' is the value of the 'category.category_name' record 2 which is referenced in the last column (chopped off a bit); so you can see how easy it is to use relations with this tool.

what is happening

It is pretty simple what is happening. For each object that is passed in the 'keywords' the IQueryable is whittled down so only the ones that 'pass' remain:

searching with 'stan' and 'pirate' (psuedocode)
IQueryable results;
results = dbDataContext._users.Where(any_of_the_specified_fields.Contains(first term));
results = results.Where(any_of_the_specified_fields.Contains(second_term));
results = results.Where(any_of_the_specified_fields.Contains(third_term));
...and so on...

Note that this only does a single db call to get the first IQueryable (in the case your IQueryable is from a database), once that one is in memory, all searches are done against it, so it is pretty fast.

the search textbox

Now that is all very simple, but rarely are your searches going to be hard-coded, so it would be simple to code in a button handler to search through a specified textbox with something like this:
protected void btnSearch_Click(object sender, EventArgs e)
  char[] search_delimiters = { ',', ' ', ';', '+' };
  string[] columns_to_search =  {"first_name", "last_name", "email_address", "category.category_name"};
  gvSearch.DataSource = new dbDataContext()._users
    .Search( columns_to_search, txtSearch.Text.Split(search_delimiters));

Pretty basic stuff there, you could also get your columns to search from a user interface like a bunch of CheckBoxes or a ListBox control.

getting more specific

If you look into the code, you can see it gets more and more specific the more you drill down into it. With the above overload, it assumes you are using all string comparable fields and all of your inputs are strings. The class's abilities do not stop there, and can get more and more specific. Say you had a massive table with the following fields: int named 'ID', DateTime named 'birthday', text named 'name' and bool named 'male'. If you simply tried the above overload with that, it would error as the types int, DateTime and bool do not have Contains() methods. But, if you specify name/type, you can use this to great advantage:
Dictionary ColumnNamesAndTypes =  new Dictionary<string, Type>();
ColumnNamesAndTypes.Add("ID", typeof(int));
ColumnNamesAndTypes.Add("first_played_videogames", typeof(DateTime));
ColumnNamesAndTypes.Add("name", typeof(string));
ColumnNamesAndTypes.Add("male", typeof(bool));

object[] search_for = {18, 25, DateTime.Parse("12/08/1981"), true, "a","b","c" };

var search_results = largeTable.Search(ColumnNamesAndTypes.ToArray(), search_for);

Now, since the Search now knows the types, it will only run valid types against the fields; for example, the 'true' object will only be run against the 'male' field, as it is the only 'bool' field, the values '18' and '25' are ints, so they will only be compared to the 'age' field of type 'int'. So, what this search would do is return all the people in the IQueryable 'largeTable' that are ages 18 and 25, who 'first_played_videogames' on 12/08/1981, that have an a,b or c in their names who are male. Now I know you can easily write these queries in Linq yourself, but if somehting changes, you are hardcoding a search change that is easy to screw up, this does it all for you.

parsing varying strings

Now there is a little more difficulty with attempting to pass in data through the magical 'google-like' single search box, but it really isn't that hard, check this out:
protected object[] parseSearchString(string search_string)
    int obInt;
    DateTime obDt;
    bool obBool;

    char[] search_delimiters = { ',', ' ', ';', '+' };
    List<object> obs = new List<object>();

    foreach (string s in search_string.Split(search_delimiters))
        if (Int32.TryParse(s, out obInt)) obs.Add(obInt);
        else if (DateTime.TryParse(s, out obDt)) obs.Add(obDt);
        else if (bool.TryParse(s, out obBool)) obs.Add(obBool);
        else obs.Add(s); // else it's a string
    return obs.ToArray();

Now I obviously didn't go through all the types there, but you get the idea. This takes in a string from a textbox and tries to parse it out to the more specific types before it defaults to a string. Now you might run into conflicts when you want to use integers as strings and such, but if you are this far in this post and still understanding things, I am sure you can figure out a way to code around that. Going back to the original example, now if I wanted to search the '_users' table for either 'category_id' (which is an integer) or the name of that category, I would just use the following:
protected void btnSearch_Click(object sender, EventArgs e)
  Dictionary<string, Type> columns_to_search = new Dictionary<string, Type>();
  columns_to_search.Add("category_id", typeof(Int32));
  columns_to_search.Add("category.category_name", typeof(string));
  gvSearch.DataSource = new dbDataContext()._users
    .Search( columns_to_search, parseSearchString(txtSearch.Text));

And as you can see that uses the above 'parseSearchString' so if I enter in '1', it is searched as in Int32:
search for '1'

And if I type in 'ninja' is is searched with a 'string' (ninja is the string value of category_id 1):
search for 'ninja'

that's it

I am hoping that at least a few of you can decipher my ramblings... hopefully you can see how this can be useful to you, and with any luck, it will save you some time and headaches. If people are interested, I can go into the code and how it works, but for now I will just leave you with the source (I even wrote comments... something I am horrible at). I am hopeing someone knows how to get the fields/types automatically from a generic IQueryable so this can be made even better - if you know how to do that, please share!!!

Linq-to-SQL vs Linq-to-Entities : Revisited

After 2 months of nothing but L2E, I feel I can give a decent comparison

Most likely you have read more than just a few of these comparisons and are tired of the debate. I too disliked L2E from the get-go but decided that my opinion was not totally grounded and that I should really understand L2E before I crap on it, so, I decided to do an entire project at work with it and get down to the nuts and bolts. Now, 2 months, a lot of frustration and some happy customers later, I can give a fully educated opinion on L2E: it is not as bad as I originally thought, in fact, it is pretty sweet in some areas, but still not as easy to use as L2S.

If you have read any of my multiple posts on Entities this will mostly be a re-hash of what I have already said. If not, this is a good summary of my findings and hopefully will help you decide.

dynamic queries

Winner: TIE
Thanks to the geniuses that wrote System.Linq.Dynamic.dll the syntax is *mostly* interchangable between the two languages (which I didn't realize when writing this). If I was forced to pick a winner, it would be L2S as there are more choices for syntax than for L2E, but that can also be viewed as a fault.

linq-to-sql -and- linq-to-entities
var results = db.branch
  .Where("branch_id == @0 || display == @1", 
    new object[] {5, "Hello"});

With L2S, you can do this as well:
var results = db.branch
  .Where("branch_id == 5 || display == \"Hello\"");

working with databound controls

Winner: Linq-to-SQL
This one is a no-brainer. After being lulled into the fact that L2S just works with so many things, I had to work backwards on problems I found with L2E. One annoyance I noticed was that if I was making an update in a GridView, it would error out unless I explicitly had the primary key in the GridView - and if I wanted it hidden, it was necessary to use css; it is documented here.

Another thing I ran across is the fact that you need to use all the required 'Include' statements in order to get a Repeater/GridView to show child values of relationships with Entities where is L2S, you could simply call the relation without any extra work.

multiple databases

Winner: Linq-to-SQL
The choice is quite simple here, as Linq-to-Entities has no native support for multiple databases.

database relation management

Winner: Linq-to-SQL
First of all, simple things such as getting foreign key values with linq-to-entities is much more difficult than in L2S; examples (written as short as I could):

int s_id = dataContext.records
  .First(r => r.record_id == 1).state_id;

int s_id = Convert.ToInt32(
  Entities.records.First(r => r.record_id == 1)

As for putting those relation values into the DB, the clear winner is L2S as well, just take a look at what it takes to set this object 'r' to have a reference to the 'city' which has a key of the integer value of 5:

r.city_id = 5;

r.cityReference.EntityKey = new EntityKey(
  "YourEntitiesNamespace.cities", "city_id", 5);

a few more...

A while back I went over some other reasons L2E annoyed me such as DataSource annoyances, relations (again) and the pain of updating your model.


Linq-to-Entities is fully capable and can do *almost* everything Linq-to-SQL can do, it just takes a bit more code some times; the almost is for multiple database utilization. L2E is a great ORM, but many of us were spoiled with L2S, so it is now up to Microsoft to live up to the expectations that they put out for us with this framework that they are deprecating. I hope and assume it will become a superior ORM, but that is in Microsoft's hands now; for the time being, it is not.

Shout it kick it on