.NET 4.0

MVC 3 AdditionalMetadata Attribute with ViewBag to Render Dynamic UI

Steve Michelotti — Mon, 31 Jan 2011 04:44:35 GMT

A few months ago I blogged about using Model metadata to render a dynamic UI in MVC 2. The scenario in the post was that we might have a view model where the questions are conditionally displayed and therefore a dynamic UI is needed. To recap the previous post, the solution was to use a custom attribute called [QuestionId] in conjunction with an “ApplicableQuestions” collection to identify whether each question should be displayed. This allowed me to have a view model that looked like this:

   1:  [UIHint("ScalarQuestion")]

   2:  [DisplayName("First Name")]

   3:  [QuestionId("NB0021")]

   4:  public string FirstName { get; set; }

5:

   6:  [UIHint("ScalarQuestion")]

   7:  [DisplayName("Last Name")]

   8:  [QuestionId("NB0022")]

   9:  public string LastName { get; set; }

10:

  11:  [UIHint("ScalarQuestion")]

  12:  [QuestionId("NB0023")]

  13:  public int Age { get; set; }

14:

  15:  public IEnumerable<string> ApplicableQuestions { get; set; }

At the same time, I was able to avoid repetitive IF statements for every single question in my view:

   1:  <%: Html.EditorFor(m => m.FirstName, new { applicableQuestions = Model.ApplicableQuestions })%>

   2:  <%: Html.EditorFor(m => m.LastName, new { applicableQuestions = Model.ApplicableQuestions })%>

   3:  <%: Html.EditorFor(m => m.Age, new { applicableQuestions = Model.ApplicableQuestions })%>

by creating an Editor Template called “ScalarQuestion” that encapsulated the IF statement:

   1:  <%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

   2:  <%@ Import Namespace="DynamicQuestions.Models" %>

   3:  <%@ Import Namespace="System.Linq" %>

   4:  <%

   5:      var applicableQuestions = this.ViewData["applicableQuestions"] as IEnumerable<string>;

   6:      var questionAttr = this.ViewData.ModelMetadata.ContainerType.GetProperty(this.ViewData.ModelMetadata.PropertyName).GetCustomAttributes(typeof(QuestionIdAttribute), true) as QuestionIdAttribute[];

   7:      string questionId = null;

   8:      if (questionAttr.Length > 0)

   9:      {

  10:          questionId = questionAttr[0].Id;

  11:      }

  12:      if (questionId != null && applicableQuestions.Contains(questionId)) { %>

  13:          <div>

  14:              <%: Html.Label("") %>

  15:              <%: Html.TextBox("", this.Model)%>

  16:          </div>

  17:  <%  } %>

You might want to go back and read the full post in order to get the full context.

MVC 3 offers a couple of new features that make this scenario more elegant to implement. The first step is to use the new [AdditionalMetadata] attribute which, so far, appears to be an under appreciated new feature of MVC 3. With this attribute, I don’t need my custom [QuestionId] attribute anymore - now I can just write my view model like this:

   1:  [UIHint("ScalarQuestion")]

   2:  [DisplayName("First Name")]

   3:  [AdditionalMetadata("QuestionId", "NB0021")]

   4:  public string FirstName { get; set; }

5:

   6:  [UIHint("ScalarQuestion")]

   7:  [DisplayName("Last Name")]

   8:  [AdditionalMetadata("QuestionId", "NB0022")]

   9:  public string LastName { get; set; }

10:

  11:  [UIHint("ScalarQuestion")]

  12:  [AdditionalMetadata("QuestionId", "NB0023")]

  13:  public int Age { get; set; }

Thus far, the documentation seems to be pretty sparse on the AdditionalMetadata attribute. It’s buried in the Other New Features section of the MVC 3 home page and, after showing the attribute on a view model property, it just says, “This metadata is made available to any display or editor template when a product view model is rendered. It is up to you to interpret the metadata information.” But what exactly does it look like for me to “interpret the metadata information”? Well, it turns out it makes the view much easier to work with. Here is the re-implemented ScalarQuestion template updated for MVC 3 and Razor:

   1:  @{

   2:      object questionId;

   3:      ViewData.ModelMetadata.AdditionalValues.TryGetValue("QuestionId", out questionId);

   4:      if (ViewBag.applicableQuestions.Contains((string)questionId)) {

   5:          <div>

   6:              @Html.LabelFor(m => m)

   7:              @Html.TextBoxFor(m => m)

   8:          </div>

   9:      }

  10:  }

So we’ve gone from 17 lines of code (in the MVC 2 version) to about 7-8 lines of code here. The first thing to notice is that in MVC 3 we now have a property called “AdditionalValues” that hangs off of the ModelMetadata property. This is automatically populated by any [AdditionalMetadata] attributes on the property. There is no more need for me to explicitly write Reflection code to GetCustomAttributes() and then check to see if those attributes were present. I can just call TryGetValue() on the dictionary to see if they were present. Secondly, the “applicableQuestions” anonymous type that I passed in from the calling view – in MVC 3 I now have a dynamic ViewBag property where I can just “dot into” the applicableQuestions with a nicer syntax than dictionary square bracket syntax. And there’s no problems calling the Contains() method on this dynamic object because at runtime the DLR has resolved that it is a generic List<string>.

At this point you might be saying that, yes the view got much nicer than the MVC 2 version, but my view model got slightly worse. In the previous version I had a nice [QuestionId] attribute but now, with the [AdditionalMetadata] attribute, I have to type the string “QuestionId” for every single property and hope that I don’t make a typo. Well, the good news is that it’s easy to create your own attributes that can participate in the metadata’s additional values. The key is that the attribute must implement that IMetadataAware interface and populate the AdditionalValues dictionary in the OnMetadataCreated() method:

   1:  public class QuestionIdAttribute : Attribute, IMetadataAware

   2:  {

   3:      public string Id { get; set; }

4:

   5:      public QuestionIdAttribute(string id)

   6:      {

   7:          this.Id = id;

   8:      }

9:

  10:      public void OnMetadataCreated(ModelMetadata metadata)

  11:      {

  12:          metadata.AdditionalValues["QuestionId"] = this.Id;

  13:      }

  14:  }

This now allows me to encapuslate my “QuestionId” string in just one place and get back to my original attribute which can be used like this: [QuestionId(“NB0021”)].

The [AdditionalMetadata] attribute is a powerful and under-appreciated new feature of MVC 3. Combined with the dynamic ViewBag property, you can do some really interesting things with your applications with less code and ceremony.

WCF REST Services Inside MVC Projects

Steve Michelotti — Thu, 23 Sep 2010 02:55:05 GMT

Recently I blogged about WCF REST services with no svc file and no config. In this post I also discussed the pros/cons of WCF services as compared to using MVC controller actions for web services and I made the case that, in many instances, WCF REST services is better than using the MVC infrastructure because WCF provides:

a more RESTful API with less work
a convenient automatic help page to assist consumers of your service
automatic format selection (i.e., xml/json) depending on HTTP headers

In any case, using both WCF REST services and MVC-style web services are *both* quite convenient – and you don’t have to choose. You can use both. In fact, you can use both inside the same web application project. However, a recent question on StackOverflow illustrates that you have to be careful how you set up your routing in order to make WCF REST services work inside MVC applications.

If you have a look at the question on StackOverflow, you’ll see the routes were originally set up like this:

   1:  routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

2:

   3:  routes.Add(new ServiceRoute("Person", new WebServiceHostFactory(), typeof(PersonService)));

4:

   5:  routes.MapRoute(

   6:      "Default", // Route name

   7:      "{controller}/{action}/{id}", // URL with parameters

   8:      new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults

   9:  );

The service route was for the WCF Service (using no *.svc file) and the last route was the standard MVC route. In most of the cases this works fine. Navigation to the root correctly lands on the HomeController’s Index method. Navigation to “/Person/help” correctly goes to the WCF REST help page and the WCF REST service can be invoked just fine. However, the action links were not correct. When formulating a simple action link like this:

   1:  <%: Html.ActionLink("Home", "Index", "Home")%>

The resulting URL being produced was: “/Person?action=Index&controller=Home” which was clearly not correct. It’s hitting the first route and thinking it should just put “Person” for the first segment. It then cannot match the “controller” or “action” tokens so it just puts them in the query string. It will attempt to go to the service but the URI is incorrect so, if it’s a WCF REST service, you’ll just get the default help page.

Of course, we know that the *order* matters for routing so what if we put the MVC route first and the service route second? In this case, we run into a different problem. If the first URI segment is “Person” then it will try to match that as the controller name and you’ll get a 404 or, if you’re using a controller factory, your IoC container won’t be able to find a controller named “PersonController”.

So how can we get the WCF REST service route and the MVC routes to play nice with each other? The simple answer: use a route contraint:

   1:  routes.MapRoute(

   2:      "Default", // Route name

   3:      "{controller}/{action}/{id}", // URL with parameters

   4:      new { controller = "Home", action = "Index", id = UrlParameter.Optional }, // Parameter defaults

   5:      new { controller = "^(?!Person).*" }

   6:  );

7:

   8:  routes.Add(new ServiceRoute("Person", new WebServiceHostFactory(), typeof(PersonService)));

Notice on line #5 above, we add a route constraint so that it will try to use the MVC route first as long as the first segment (where the “controller” token is positioned) is not the “Person” string which matches where we want our WCF REST service to be. If it is “Person”, then it will fall through to the service route and correctly point to our WCF REST service.

One other interesting note when using service routes in MVC applications – anytime you’re going beyond the default MVC routes, I highly recommend you unit test your routes. This can be done very easily with the TestHelper that comes with MvcContrib. It makes it trivial to unit test routes like this:

   1:  [TestMethod]

   2:  public void default_path_should_be_able_to_match_controller()

   3:  {

   4:      "~/".Route().ShouldMapTo<HomeController>();

   5:  }

The unfortunate caveat here is that you cannot use this when you’re combining service routes. If you do, you’ll get this exception when you initialize your routes at the start of the unit test by invoking the static RegisterRoutes() method: “System.InvalidOperationException: System.InvalidOperationException: 'ServiceHostingEnvironment.EnsureServiceAvailable' cannot be invoked within the current hosting environment. This API requires that the calling application be hosted in IIS or WAS.” Fortunately, we can still use Phil Haack’s Route Debugger:

With the URL of “/Person/23”, it correctly matches my service route for my WCF service.

WCF REST and MVC are both great and they should be used *together* when appropriate.

C# 4 Named Parameters for Overload Resolution

Steve Michelotti — Tue, 16 Mar 2010 04:14:02 GMT

C# 4 is getting a new feature called named parameters. Although this is a stand-alone feature, it is often used in conjunction with optional parameters. Last week when I was giving a presentation on C# 4, I got a question on a scenario regarding overload resolution that I had not considered before which yielded interesting results. Before I describe the scenario, a little background first.

Named parameters is a well documented feature that works like this: suppose you have a method defined like this:

   1:  void DoWork(int num, string message = "Hello")

   2:  {

   3:      Console.WriteLine("Inside DoWork() - num: {0}, message: {1}", num, message);

   4:  }

This enables you to call the method with any of these:

   1:  DoWork(21);

   2:  DoWork(num: 21);

   3:  DoWork(21, "abc");

   4:  DoWork(num: 21, message: "abc");

and the corresponding results will be:

Inside DoWork() - num: 21, message: Hello
Inside DoWork() - num: 21, message: Hello
Inside DoWork() - num: 21, message: abc
Inside DoWork() - num: 21, message: abc

This is all pretty straight forward and well-documented. What is slightly more interesting is how resolution is handled with method overloads. Suppose we had a second overload for DoWork() that looked like this:

   1:  void DoWork(object num)

   2:  {

   3:      Console.WriteLine("Inside second overload: " + num);

   4:  }

The first rule applied for method overload resolution in this case is that it looks for the most strongly-type match first. Hence, since the second overload has System.Object as the parameter rather than Int32, this second overload will never be called for any of the 4 method calls above. But suppose the method overload looked like this:

   1:  void DoWork(int num)

   2:  {

   3:      Console.WriteLine("Inside second overload: " + num);

   4:  }

In this case, both overloads have the first parameter as Int32 so they both fulfill the first rule equally. In this case the overload with the optional parameters will be ignored if the parameters are not specified. Therefore, the same 4 method calls from above would result in:

Inside second overload: 21
Inside second overload: 21
Inside DoWork() - num: 21, message: abc
Inside DoWork() - num: 21, message: abc

Even all this is pretty well documented. However, we can now consider the very interesting scenario I was presented with. The question was what happens if you change the parameter name in one of the overloads. For example, what happens if you change the parameter *name* for the second overload like this:

   1:  void DoWork(int num2)

   2:  {

   3:      Console.WriteLine("Inside second overload: " + num2);

   4:  }

In this case, the first 2 method calls will yield *different* results:

   1:  DoWork(21);

   2:  DoWork(num: 21);

results in:

Inside second overload: 21
Inside DoWork() - num: 21, message: Hello

We know the first method call will go to the second overload because of normal method overload resolution rules which ignore the optional parameters. But for the second call, even though all the same rules apply, the compiler will allow you to specify a named parameter which, in effect, overrides the typical rules and directs the call to the first overload. Keep in mind this would only work if the method overloads had different parameter names for the same types (which in itself is weird). But it is a situation I had not considered before and it is one in which you should be aware of the rules that the C# 4 compiler applies.

.NET 4.0 and Visual Studio 2010 Presentation at Microsoft

Steve Michelotti — Fri, 22 Jan 2010 18:08:40 GMT

On February 4th, I will be presenting .NET 4.0 and Visual Studio 2010 at the Microsoft office in Reston as part of my company’s continued efforts to provide education on Microsoft technologies. This presentation will cover a wide breadth of technologies that are being launched by Microsoft this year. The presentation is geared towards technical decision makers including Architects, CTO, CIO, Project Managers, IT Managers, and senior development resources. This a totally free Microsoft sponsored event that is intended to provide a solid foundation on the vast landscape of technologies being released and how best they can be leveraged in your organization. The topics will include:

.NET Framework 4 enhancements
Visual Studio 2010
Parallel Extensions
C# 4.0 & VB10 language enhancements
ASP.NET 4
Microsoft AJAX Library
MVC 2
Entity Framework 4
WCF Data Services
WCF 4 & REST
Workflow Foundation 4
AppFabric
AppFabric Caching
Silverlight

This event is free and you can register here. Hope to see you there.

Comparing Entity Framework 4 New Stored Procedure Support to LINQ to SQL

Steve Michelotti — Thu, 17 Dec 2009 04:24:10 GMT

The next version of Entity Framework has many new features, many of which are enabling it to catch up with features previously available in other frameworks like LINQ to SQL. One of these new features is the updated stored procedure support. In previous versions of EF, working with stored procedures was quite limited and really only usable with CRUD operations that were mapped to already defined entities. With EF 4, you can start with your stored procedure and have the designer automatically generate return types. Essentially it will “sense” the shape of the parameters and (if applicable) SELECT statement and generate types that match it or allow you to map it to an already existing type. This is certainly a great new feature to be adding but, at the same time, these stored procedure features have been in LINQ to SQL since version 1.

Although the features are similar between EF 4 and LINQ to SQL, the implementation isn’t exactly the same. Suppose we have a typical Contact object that looks like this:

   1:  public class Contact

   2:  {

   3:      public Contact()

   4:      {

   5:          this.Addresses = new List<Address>();

   6:      }

7:

   8:      public int ContactId { get; set; }

   9:      public string FirstName { get; set; }

  10:      public string LastName { get; set; }

  11:      public string Email { get; set; }

  12:      public string Title { get; set; }

  13:      public ICollection<Address> Addresses { get; set; }

  14:  }

and stored procedure to insert a new contact that takes all of these properties as parameters (with an output parameter for the ContactID since it’s a PK Identity). If we use the typical edmx approach, we get generated code for this stored procedures that looks like this:

   1:  public int SaveContact(ObjectParameter contactID, global::System.String firstName, global::System.String lastName, global::System.String company, global::System.String title, global::System.String email)

   2:  {

   3:      ObjectParameter firstNameParameter;

   4:      if (firstName != null)

   5:      {

   6:          firstNameParameter = new ObjectParameter("FirstName", firstName);

   7:      }

   8:      else

   9:      {

  10:          firstNameParameter = new ObjectParameter("FirstName", typeof(global::System.String));

  11:      }

12:

  13:      ObjectParameter lastNameParameter;

  14:      if (lastName != null)

  15:      {

  16:          lastNameParameter = new ObjectParameter("LastName", lastName);

  17:      }

  18:      else

  19:      {

  20:          lastNameParameter = new ObjectParameter("LastName", typeof(global::System.String));

  21:      }

22:

  23:      ObjectParameter companyParameter;

  24:      if (company != null)

  25:      {

  26:          companyParameter = new ObjectParameter("Company", company);

  27:      }

  28:      else

  29:      {

  30:          companyParameter = new ObjectParameter("Company", typeof(global::System.String));

  31:      }

32:

  33:      ObjectParameter titleParameter;

  34:      if (title != null)

  35:      {

  36:          titleParameter = new ObjectParameter("Title", title);

  37:      }

  38:      else

  39:      {

  40:          titleParameter = new ObjectParameter("Title", typeof(global::System.String));

  41:      }

42:

  43:      ObjectParameter emailParameter;

  44:      if (email != null)

  45:      {

  46:          emailParameter = new ObjectParameter("Email", email);

  47:      }

  48:      else

  49:      {

  50:          emailParameter = new ObjectParameter("Email", typeof(global::System.String));

  51:      }

52:

  53:      return base.ExecuteFunction("SaveContact", contactID, firstNameParameter, lastNameParameter, companyParameter, titleParameter, emailParameter);

  54:  }

It’s good that’s generated code and we don’t have to worry about writing that ourselves but it’s not the prettiest code to look at. Let’s take a look at the exact same stored procedure call in a LINQ to SQL data context:

   1:  [Function(Name = "dbo.SaveContact")]

   2:  public int SaveContact(ref Nullable<int> contactID, string firstName, string lastName, string company, string title, string email)

   3:  {

   4:      IExecuteResult result = this.ExecuteMethodCall(this, (MethodInfo)MethodInfo.GetCurrentMethod(), contactID, firstName, lastName, company, title, email);

   5:      contactID = (Nullable<int>)result.GetParameterValue(0);

   6:      return (int)result.ReturnValue;

   7:  }

The first most obvious difference is that’s 54 lines of code for EF 4 and 7 lines of code for LINQ to SQL. Second, LINQ to SQL allows you to just pass in the primitive types to the built-in ExecuteMethodCall() method whereas EF 4 wants a list of ObjectParameter types for its ExecuteFunction() method. Third, LINQ to SQL can reflect over the parameters to figure out, by name, which parameters map to which stored procedure parameters (LINQ to SQL also provides the [Parameter] attribute if the names or types differ and need to be explicitly mapped). EF, on the other hand, wants the string for the name explicitly set (e.g., “FirstName”, “LastName”, etc.). Also, EF 4 specifies the name of the stored procedure as a parameter to the ExecuteFunction() method, whereas LINQ to SQL specifies it in the [Function] attribute which decorates the method. Finally, the last interesting difference that I see is in regards to the contact ID property. That is the PK Identity column that gets assigned from the database on insert. LINQ to SQL automatically exposes that as a ref parameter (which is an API that makes sense from a C# perspective) and assigns the values after the stored procedure has been invoked via the GetParameterValue() method. EF 4, on the other hand, exposes that parameter as an actual ObjectParameter (rather than a “ref int”) and all the rest of the parameters as their natural primitives. So the responsibility is on the caller to create the ObjectParameter for the PK property but not for the other ones. This allows the caller to have a reference to the variable so that, in the case of output parameters, it can get at the new value that was just assigned by the database.

Certainly there are pros and cons of each approach. But I doubt I would be putting myself in the minority to say that I prefer the (much) more succinct API that LINQ to SQL provides. So, while I love the fact that EF 4 is now allowing me to call stored procedures in a similar way to what I had with LINQ to SQL, I’m not absolutely thrilled with the API.

But, digging a little deeper, how can I add some re-usable methods to be able to give my EF 4 a more succinct API?

The first thing I want to do is to get an easy way to create all of those ObjectParameters automatically from their primitive types without all the IF statements checking to see if each one is null. If I want to add on to the designer generated code, I can create this method in a partial class. Otherwise, if I’m using the “code only” approach, I can put this method in my own base ObjectContext class xxxxx:

   1:  public class SmartObjectContext : ObjectContext

   2:  {

   3:      protected ObjectParameter[] GetObjectParameters(MethodInfo methodInfo, params object[] parameters)

   4:      {

   5:          var objectParameters = new ObjectParameter[parameters.Length];

6:

   7:          var methodParams = methodInfo.GetParameters();

   8:          for (int i = 0; i < parameters.Length; i++)

   9:          {

  10:              var paramName = methodParams[i].Name;

  11:              var paramType = methodParams[i].ParameterType;

  12:              var paramValue = parameters[i];

  13:              if (paramValue == null)

  14:              {

  15:                  objectParameters[i] = new ObjectParameter(paramName, paramType);

  16:              }

  17:              else

  18:              {

  19:                  objectParameters[i] = new ObjectParameter(paramName, parameters[i]);

  20:              }

  21:          }

  22:          return objectParameters;

  23:      }

  24:  }

This method is clearly not as robust as the LINQ to SQL implementation which optionally takes into account parameter attributes if they exist to further customize the mapping, but it gets the job done. This now allows my (previously 54 lines) SaveContact() method to now look like this:

   1:  public int SaveContact(ref int contactID, string firstName, string lastName, string company, string title, string email)

   2:  {

   3:      var objParams = this.GetObjectParameters((MethodInfo)MethodInfo.GetCurrentMethod(), contactID, firstName, lastName, company, title, email);

   4:      var result = this.ExecuteFunction("SaveContact", objParams);

   5:      contactID = (int)objParams.First(o => o.Name == "contactID").Value;

   6:      return result;

   7:  }

Just by adding this one method to a base class (or current class if you’re using a partial) I was able to reduce my SaveContact() method from 54 lines to 7 lines, and allow the API to be primitives for all parameters including a “ref int” for the PK Identity rather than an ObjectParameter.

I can also simplify this even further if I’m invoking stored procedures that are not assigning output parameters. For example, suppose you have a simple GetContact stored procedure which takes a single integer contactID as the parameter to the stored procedure. The auto-generated EF 4 code looks like this:

   1:  public ObjectResult<Contact> GetContact(Nullable<global::System.Int32> contactID)

   2:  {

   3:      ObjectParameter contactIDParameter;

   4:      if (contactID.HasValue)

   5:      {

   6:          contactIDParameter = new ObjectParameter("ContactID", contactID);

   7:      }

   8:      else

   9:      {

  10:          contactIDParameter = new ObjectParameter("ContactID", typeof(global::System.Int32));

  11:      }

12:

  13:      return base.ExecuteFunction<Contact>("GetContact", contactIDParameter);

  14:  }

Notice this is using a different ExecuteFunction() method that is generic and is strongly-typed to the Contact class in this instance. I can create my own generic ExecuteFunction() method that encapsulates the creation of the ObjectParameter(s) and also put that in my base (or partial) ObjectContext:

   1:  public ObjectResult<T> ExecuteFunction<T>(string functionName, MethodInfo methodInfo, params object[] parameters)

   2:  {

   3:      var objParams = this.GetObjectParameters(methodInfo, parameters);

   4:      return base.ExecuteFunction<T>(functionName, objParams);

   5:  }

What this now allows me to do is to refactor my GetContact() method to now look like this:

   1:  public ObjectResult<Contact> GetContact(Nullable<int> contactID)

   2:  {

   3:      return this.ExecuteFunction<Contact>("GetContact", (MethodInfo)MethodInfo.GetCurrentMethod(), contactID);

   4:  }

Essentially this is now down to 1 meaningful line of code.

A couple of other things to keep in mind – first, the technique of these helper methods can be used regardless of whether you are using EF 4 in “data first”, “model first”, or “code only” scenarios. Secondly, if you are using edmx files, EF 4 now allows you to customize the generated code that is produced via T4 templates. So if you don’t like the code that the EF 4 designer is creating for you out of the box, change it!

One final note on EF 4 stored procedure support: apparently it does *not* support stored procedures that have multiple result sets – this also has been available since the first version of LINQ to SQL via IMultipleResults. I’m told this functionality can be added to EF with the EF Extensions library but I have yet to use it myself.

I’m still in the process of exploring all of the new features being added to EF 4. While some of them are quite interesting (e.g., fluent mappings, etc.), many of the other features being added have already been available in other frameworks like LINQ to SQL. Definitely good to seem them being added to EF 4 now as well.

Attaching Modified Entities in EF 4

Steve Michelotti — Sat, 28 Nov 2009 03:12:10 GMT

Lately I’ve been working with EF 4.0 and finding that many of the new features are catching up with the features previously available in other framework like LINQ to SQL. One example of this is the ability to easily attach objects (for example, disconnected objects that come in from another tier). For example, imagine you had a web service where a consumer submitted an object to get saved – you’d want to instantiate a new context, attach the incoming entity, and save the object. In previous versions of EF, this was not a trivial thing to do. However, this was always quite easy to do in LINQ to SQL by doing this:

   1:  using (var dataContext = new MyDataContext())

   2:  {

   3:      dataContext.Contacts.Attach(someEntity, true);

   4:      dataContext.SubmitChanges();

   5:  }

Notice the second Boolean parameters of the Attach() method – this instructs the context that the entity should treated “as modified” so that an UPDATE command should be issued for that entity when SubmitChanges() gets called (LINQ to SQL also provides an AttachAll() method for collections). You can now do the same thing in EF 4 like this (I’m using POCO and Code Only here):

   1:  using (var dataContext = new MyDataContext())

   2:  {

   3:      dataContext.Contacts.Attach(contact);

   4:      dataContext.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified);

   5:      dataContext.SaveChanges();

   6:  }

This is a huge leap forward from previous versions of EF but notice that this actually takes one more line of code than its LINQ to SQL counterpart because an explicit call to the ObjectManager’s ChangeObjectState() method must be called. Although this might appear to be a slight inconvenience, it is possible to write a couple of extension methods to simplify this since the ObjectSet’s all have a reference to the parent Context:

   1:  static class ContextExtensions

   2:  {

   3:      public static void AttachAsModified<T>(this ObjectSet<T> objectSet, T entity) where T : class

   4:      {

   5:          objectSet.Attach(entity);

   6:          objectSet.Context.ObjectStateManager.ChangeObjectState(entity, EntityState.Modified);

   7:      }

8:

   9:      public static void AttachAllAsModified<T>(this ObjectSet<T> objectSet, IEnumerable<T> entities) where T : class

  10:      {

  11:          foreach (var item in entities)

  12:          {

  13:              objectSet.Attach(item);

  14:              objectSet.Context.ObjectStateManager.ChangeObjectState(item, EntityState.Modified);

  15:          }

  16:      }

  17:  }

This allows you to now save like this:

   1:  using (var dataContext = new MyDataContext())

   2:  {

   3:      dataContext.Contacts.AttachAsModified(contact);

   4:      dataContext.SaveChanges();

   5:  }

This is pretty straight forward and certainly not very complex. However, it is promising that EF is moving in the direction of better enabling these simple scenarios as compared with previous versions.