ReSharper 4.0 - Cool Features

13 06 2008

There are quite a few new features to ReSharper 4.0 that are great, but it’s the little things that really can impress and speed up usage.  A few of my favorites are below.

camelHumps. :)

ReSharper now supports Go To > and statement completion according to camel casing.  If you’re like me, you tend to write normal sentences in camel case—it’s just habit.

Using the camel casing, it picks up the variable I just created, not the class.

Lambda support.

I’ve become addicted to the simplicity of lambdas—they express intent and you can read them like sentences.  ReSharper 4 does an excellent job of digging into the anonymous type and pulling up IntelliSense information.

ResponseChoicesController()

.SelectOne(x =>

x.IsDefault &&

x.ResponseTypeId == responseTypeId)

From the ResponseChoicesController, select one that meets the requirements that IsDefault is true and ResponseTypeId is equal to the specified responseTypeId.  To me, and I’m sure I’m odd, that is easier to read than the “written” LINQ code.

Convert Static to Extension.

This is FANTASTIC for revamping existing code to take full advantage of the .NET 3.5 Framework.  I’ve been working on a project the past few weeks to migrate a .NET 2.0 project using Enterprise Library 3 up to 3.5 and LINQ-to-SQL and this addition has been fantastic to move data and business logic into controllers and the LINQ data context.

 





ReSharper 4.0 Released!

10 06 2008

Finally, after quite a long wait and an exciting EAP period, ReSharper has been dubbed “done” by the guys and gals at JetBrains.

So far, so good on this side.  I’ve kept up-to-date almost every release on my production machine and rarely ran into any issues.

Now, to talk the bosses into upgrading!





Deep Copy Cloning of LINQ Entity Objects - Not Deep Enough

5 06 2008

Yesterday, I wrote about a great IL solution to deep copying LINQ objects.  Unfortunately, it’s not quite deep enough. :(

The problem lies in the entity sets related to LINQ objects.  For example, in what I’m working on, the Report object contains Marks (grades) based on a foreign key relationship.  The previously discussed IL cloning method copies the records, but because it doesn’t generate new primary keys for those, it throws:

“An attempt has been made to Attach or Add an entity that is not new, perhaps having been loaded from another DataContext.  This is not supported.”

I’ve tried zeroing out the PK fields just as I did with the report object iself—no dice.  Removing the Marks (by setting them equal to either null or new EntitySet<Mark>()) and no dice.

The only way I think I can get around it would be to break the FK relationship, clone the report (which would return a new Id), and then copy each of the Marks objects separately with some sort of loop (similar to below):

foreach (var mark in

new MarksController().SelectAll(oldReport.Id))

{

var newMark = new Mark {

              IndicatorId = mark.IndicatorId,

ReportId = newReport.Id,

             ResponseChoiceId = mark.ResponseChoiceId

});

}

That defeats the purpose though… ugh.

Back to the drawing board!

Tags: , , , ,




ReSharper 4.0 is now RC!

5 06 2008

The first RC for ReSharper 4.0 is out—pick it up! Nice!





Deep Copy Cloning of LINQ Entity Objects

4 06 2008

Unfortunately, there’s no real slick way (built into LINQ) to clone LINQ entity objects. 

My need was simple:  Take a record, duplicate it, change a few select values, and then dump it back into the data source to generate a new primary key.

But I couldn’t find a good way to get a deep copy using ICloneable and sure as heck didn’t want to do it manually. 

After a bit of searching, I came across a great blog posting that discussed using direct IL to make deep copies of objects.  The blog post looked promising.  As the author explains, “[t]he basic thing that it does is, create a DynamicMethod, get the ILGenerator, emit code in the method, compile it to a delegate, and execute the delegate.”  Sounds simple enough.

NOTE: Check out the blog post (here) for the full source code; the modifications I made are mostly domain specific—the implementation works great as it is.

I added the method into the GenericController that I use to implement LINQ and the results were brillant!

// Clone the entity based on the original report.

var newReport = this.Clone(SelectOne(originalReportId));

           

// Remove the ID to make it generate a new primary key.

newReport.Id = 0;

           

//  Change the necessary information.

newReport.EnteredBy = enteredBy;

newReport.Quarter = quarter;

 

// Insert the imported report into the system and save changes.

Insert(newReport, true);

 

// Now that the imported report has a primary key, return it.

return newReport;

Because .Clone is a virtual method of my Controller’s base class (public virtual T Clone<T>(T entity)), it applies to any type that I happen to pass into it.  In the code example above, this Import method is in the ReportsController and SelectOne returns a Report object, so Clone generates a clone based on the constructor and fields of that type.  Implementation with any other LINQ controller works just the same—excellent for reuse.

Since an integer primary key, Id in the code above, cannot be null, setting it to zero (0) will force the SQL processor to generate a new primary key when the record is entered into the database—which is exactly what we want.

Very pleased with the implementation of this and how slick (and quickly) it works.

Tags: , , , ,




Comparing ForEach Overheads

16 04 2008

I’ve spent a bit of time dinking with foreach this morning while waiting for a customer to respond… and figured I’d put the ForEach extension method to a test.

Using a generic form of the Benchmark utility class, I brought in a heap of data from a database and iterated through it 1 million (1,000,000) times, each time adding the record Id into a generic list.

The benchmark doesn’t include the time to fetch the data or the creation of the list, simply the foreach and method inside the foreach, which is identical in both test cases.

The data source, Report.GetReports, is returning approximately 12,000 records (Report objects, in this case) from an Oracle database; so each ForEach is iterating through those 12,000 records… 1 million times.

Assumptions

  • I expected the ToList() conversion to add a great deal of weight.
  • I expected the standard foreach methodology to fly by.

Results

The results were quite shocking.

As with most technologies or “cool things” like extension methods, there are usually tradeoffs and those are almost always in regards to performance.

And, it is slower… marginally.  I ran the entire battery of tests ten times and all but once the foreach statement came out ahead; however, the margins were usually in the hundredths of seconds.

My assumption that the ToList() would add “a great deal of weight” is a bit off.  While I’m not certain, I am pretty sure that a few milliseconds accounts to the conversion—just not as much as I expected.  Overall, I’m pretty shocked to see the numbers as close as they are.  A bit of that falls to CPU cycles as well; the margin between the two is relatively the same throughout.

Raw Results

Test #0

Ext: 00:00:01.0781181

foreach: 00:00:01.0468683

Test #1

Ext: 00:00:01.1049239

foreach: 00:00:01.1093679

Test #2

Ext: 00:00:01.0937430

foreach: 00:00:01.0781181

Test #3

Ext: 00:00:01.2187422

foreach: 00:00:01.1093679

Test #4

Ext: 00:00:01.2656169

foreach: 00:00:01.0937430

Test #5

Ext: 00:00:01.2343671

foreach: 00:00:01.1874924

Test #6

Ext: 00:00:01.2187422

foreach: 00:00:01.0937430

Test #7

Ext: 00:00:01.3124916

foreach: 00:00:01.0624932

Test #8

Ext: 00:00:01.2499920

foreach: 00:00:01.1718675

Test #9

Ext: 00:00:01.2499920

foreach: 00:00:01.0624932

Here’s the code for the entire test:

var mark = new Benchmark();

var stmt1 = Report.GetReports(teacherId, quarter, year);

 

for (int iteration = 0; iteration < 10; iteration++)

{

var list1 = new List<int>();

var list2 = new List<int>();

mark.Start();

for (int i = 0; i < 1000000; i++)

{

                     stmt1.ToList().ForEach(x => list1.Add(x.Id));

}

mark.Stop();

 

       var extension = mark.ElapsedTime.ToString();

 

mark.Start();

for (int i = 0; i < 1000000; i++)

{

foreach (var x in stmt1)

               {

                     list2.Add(x.Id);

}

}

 

mark.Stop();

       var fe = mark.ElapsedTime.ToString();

 

       Console.WriteLine(“Test #{0}, Ext: {1}, foreach: {2}”,

              iteration, extension, fe);

}





SQL Server 2005: Stored Procedures Executor Role

7 04 2008

Granting permissions to use stored procedures is something I rarely do… in most of my applications, I either use .NET SQL projects and compile my SQL code OR everything is handled in the data layer/LINQ code.

We’ve had a recent consult project and the coders use stored procedures heavily.  That’s cool—to each their own.  Performance seems good on the system and the procedures are pretty small.

But… remembering to readd the EXECUTE permission to the user account on each reload is REALLY annoying.  I’d read this somewhere (if I can find the original source, I’ll cite it) ages ago and dragged it out of the code library.  A quick bit of TSQL code to create a database role that SHOULD exist out of the box—one that can execute stored procedures.

/* Create a new role for executing stored

   procedures */

CREATE ROLE db_executor

 

/* Grant stored procedure execute rights

   to the role */

GRANT EXECUTE TO db_executor

 

/* Add a user to the db_executor role */

EXEC sp_addrolemember ‘db_executor’, ‘AccountName’

Quite easy and it makes it VERY easy to control EXECUTE permissions for your accounts.





Adding Parameters to the Generic BindListControl Method

25 03 2008

Yesterday, I blogged about a generic method I created that could take a series of parameters and bind most any type of IEnumerable data source to most any type of DataBoundControl control.  I needed a simple and portable method (so that I could eventually toss it into the base helper library I use).

Unfortunately, the post didn’t cover something quite common—what happens when your data methods have parameters?  Integers, strings, even objects (passing a User object, etc).

For this, I’ll be modifying our “third attempt,” which, for now is, is the final version of the code.  Here’s the change. 

protected void BindDataControl

<TDataControlType, TEnumerableType, TDataSourceClass>

       (bool hasBeenModified, string sessionVariable,

              TDataControlType dataControl,

string dataSourceMethod,

              TDataSourceClass dataSourceClass,

object[] methodArguments)

where TDataControlType : DataBoundControl,

              new() where TEnumerableType : IEnumerable,

             new() where TDataSourceClass : class

{

// If session is null or has been modified

       // (thus invalidated), update the session state.

       if (Session[sessionVariable] == null || hasBeenModified)

       {

              // Invoke the specified method that

//creates our data source.

             var data = dataSourceClass.GetType().InvokeMember(

                     dataSourceMethod,

                    BindingFlags.InvokeMethod |

                    BindingFlags.NonPublic |

                    BindingFlags.Public |

                    BindingFlags.Instance,

                    null,

dataSourceClass, methodArguments);

// Add it to session.

             Session.Add(sessionVariable, data);

}

 

// Read the data from session and bind the data control.

dataControl.DataSource =

(TEnumerableType)Session[sessionVariable];

 

dataControl.DataBind();

}

Pay close attention to the new methodArguments object array.  I’ve bolded them in the code above.  The InvokeMember reflection method allows for arguments to be passed, so I simply opened that up to the calling method.

To use this, here’s an example that takes the Page.User property and passes it to a LINQ data context method:

BindDataControl<ListView, List<Gallery>, WebGalleryDataContext>

(true,

       “GalleryList”,

       GalleriesList,

       “GetGalleriesByRole”,

       db,

       new [] { Page.User });

or, pulling from the QueryString:

BindDataControl<ListView, List<WebFile>, WebGalleryDataContext>

(true,

       “CurrentGallery”,

       lv,

       “GetWebFilesByGalleryName”,

       db,

new [] {Request.QueryString["id"]});

and passing multiple arguments with different base types:

BindDataControl

<ListView, List<IGrouping<Gallery, WebFile>>,

WebGalleryDataContext>

       (true,

       “ChangesSinceLastVisit”,

       listViewTest,

       “GetAllSinceLastVisit”,

       db,

       new object[]

{Convert.ToDateTime(Session["LastLoginDate"]),

Page.User});

Cool.





Using Generics to Update DataBoundControls - A Prototype

24 03 2008

NOTE: This is a prototype, an idea, a random thought expressed aloud (well, in type).  The code explains a concept and isn’t “tested” or production worthy (in my opinion). 

Feedback is always appreciated. :)  This is also what happens when I have a week off work and come back with ‘ideas.’

I find that a few of my projects, like the WebGallery2, all have a similar functionality.  On pages with GridViews, ListViews (which, I’m slowly replacing all my GridViews with), or other DataBoundControls, I follow a common theme for data binding:

If the data set will be cached or in session, is that session/cache null OR has the data set been explicitly modified?

  1. true – regenerate the data set and repopulate session/cache.
  2. false – read the current data set from session/cache to the control.

In a single instance, the code to do this might look like:

private void BindList(bool hasBeenModified, string sessionVariable)

{

       // If our session variable is null or the data has

// been explicitly modified, then rebuild the session variable.

if (Session[sessionVariable] == null || hasBeenModified)

              Session[sessionVariable] =

db.GetWebFilesByGalleryName(this.Id);

 

resultsListView.DataSource =

Session[sessionVariable] as List<WebFile>;

 

resultsListView.DataBind();

}

This would then be called with:

BindList(true, “CurrentGallery”);

However, this code really bothers me. 

The data source (the db.GetWebFilesByGalleryName method), data bound control (the resultsListView), and the type of the data source (List<WebFile&gt ;) are all hard coded.

How could this helper method use generics to add a bit of resuability?  What about when I want to use a GridView instead of a ListView, or have a List<Gallery>, List<String>, string[] of information?

First Attempt

The first attempt works.  It takes the generics as anticipated and is rather easy to use.

protected void BindDataControl<TDataControlType, TEnumerableType>

(bool hasBeenModified, string sessionVariable,

              TDataControlType dataControl, TEnumerableType dataSource)

where TDataControlType : DataBoundControl,

              new() where TEnumerableType : IEnumerable

{

// Add the dataSource to session.

       if (Session[sessionVariable] == null || hasBeenModified)

              Session.Add(sessionVariable, dataSource);

 

// Read the data from session and bind the data control.

       dataControl.DataSource =

(TEnumerableType)Session[sessionVariable];

       dataControl.DataBind();

}

The constructor here has both generic parameters and standard parameters.

  • TDataControlType has a generic constraint that requires it to be part of or a subclass of DataBoundControl (GridView, ListView, etc).
  • TEnumerableType requires the source to inherit from IEnumerable (List, Array, etc).

Here are a few examples of using it this bit of code:

var gv = new GridView();

this.Page.Controls.Add(gv);

BindDataControl<GridView, Array>(

true,   // this is new, so build a session variable.

       “test”, // the session variable

       gv,     // the Id of our GridView

       new[]   // The data source, an array.

              { “hello”, “world” });

When rendered, we have a simple GridView with our two data items.

GridView and Array data source.

What about a more complicated example using collections and a ListView? On the current build of the WebStorage2 project, the galleries are built in a similar method (see this post for more details).  I could just as easily replace the logic in Show.aspx’s Page_PreRender with:

BindDataControl<ListView, List<WebFile>>(

true,

       “CurrentGallery”,

       lv,

       db.GetWebFilesByGalleryName(Request.QueryString["id"]));

So what’s the downfall to this method? 

Downfall #1: It’s a performance nightmare. AFAIK, when passing a method (which GetWebFilesByGalleryName is a method from my LINQ DataContext), it is evaluated immediately.  So, with that in mind, the hasBeenModified is irrelevant—it may not NEED to update the session, but the method will still go out, search the database, and return the results.  That’s a bad deal.

What I don’t know and am not sure how to check is whether or not the lazy/delayed loading in LINQ would balance out this at all.  Ideas?

Second Attempt

The second attempt adds in a bit more “generic” and a lot more reflective.  By adding a reference to System.Reflection, we can simply pass a string reference to a “builder” method rather than the method it self—thus saving the prefabrication of the data source when it’s not really needed.

protected void BindDataControl<TDataControlType, TEnumerableType>

(bool hasBeenModified,

              string sessionVariable,

             TDataControlType dataControl,

             string dataSourceMethod)

where TDataControlType : DataBoundControl,

              new() where TEnumerableType : IEnumerable

{

// If session is null or has been modified (thus invalidated),

       // update the session state.

       if (Session[sessionVariable] == null || hasBeenModified)

       {

              // Invoke the specified method that

// creates our data source.

             var data = Page.GetType().InvokeMember(

dataSourceMethod,.

BindingFlags.InvokeMethod |

                    BindingFlags.NonPublic |

                    BindingFlags.Instance,

                    null, this, null);

 

// Add it to session.

             Session.Add(sessionVariable, data);

}

 

// Read the data from session and bind the data control.

       dataControl.DataSource =

(TEnumerableType)Session[sessionVariable];

      

dataControl.DataBind();

}

In this method, the Page.GetType().InvokeMember method iterates through the methods on the page, finds the one that matches the string name passed to it, and executes it. 

Then, with our “data” results, the rest is the same as the previous method.

Unfortunately, I cannot pass the LINQ direct lookup anymore because the scope of InvokeMember is limited to the calling page.  I’ll need to create another little method, called GetResults in this case, to do the query for me.

protected List<WebFile> GetResults()

{

return db.GetWebFilesByGalleryName(Request.QueryString["id"]);

}

And the updated BindDataControl method:

BindDataControl<ListView, List<WebFile>>(
  false,
  “CurrentGallery”,
  lv,
  “GetResults”);

Now, since our constructor does not contain the method to fetch our data, simply a string, the results are not refetched each time the method is called—only when the requirements are met further in the code.

Downfall #1: This method requires an additional “helper” method on every page to fetch the data.  You can’t access methods outside of the page—or can you?

Downfall #2: What happens if you need to pass parameters to your InvokeMember?  You CAN, but the syntax is nasty and becomes even more difficult if the parameters are not always in the same order (which doubtfully they would be if you’re using generics).

Third Attempt

The third attempt looks more like the signature from Hell than a real method.  There had to be a way around the “stuck on this page” snafu with the second attempt… and there was, by specifying the class too using a generic.

protected void BindDataControl

<TDataControlType, TEnumerableType, TDataSourceClass>

(bool hasBeenModified, string sessionVariable,

              TDataControlType dataControl,

string dataSourceMethod,

TDataSourceClass dataSourceClass)

where TDataControlType : DataBoundControl,

              new() where TEnumerableType : IEnumerable,

             new() where TDataSourceClass : class

{

// If session is null or has been modified

// (thus invalidated), update the session state.

       if (Session[sessionVariable] == null || hasBeenModified)

       {

              // Invoke the specified method that

// creates our data source.

             var data = dataSourceClass.GetType().InvokeMember(

dataSourceMethod,

                     BindingFlags.InvokeMethod |

                    BindingFlags.NonPublic |

                    BindingFlags.Public |

                    BindingFlags.Instance,

                    null, dataSourceClass, null);

 

// Add it to session.

Session.Add(sessionVariable, data);

}

 

// Read the data from session and bind the data control.

dataControl.DataSource =  

(TEnumerableType)Session[sessionVariable];

 

dataControl.DataBind();

}

Good grief. 

This method adds a third generic to the constructor—TDataSourceClass—as well as the additional constraint requirement.  I’ve also added an additional BindingFlag—Public—since most of the methods in LINQ DataContext classes are decorated public.

Rather than pulling from this.Page, we’re now calling InvokeMember from the parameter class and returning the results to the calling page.  There’s one other change—rather than looking at “this” as the Binder parameter, we’re referencing the class passed along in the constructor—the dataSourceClass.

BindDataControl<ListView, List<WebFile>, WebGalleryDataContext>(
    true,
    “CurrentGallery”,
    lv,
    “GetWebFiles”,
    db);

Here we have two additional parameters, the generic parameter, TDataSourceClass, that I’ve passed the LINQ Data Context into to define the Type of the dataSourceClass parameter passed later in the constructor. 

“Verbalized”, the method’s generics read: BindDataControl to a ListView with the expected data format of a List<WebFile> using the WebGalleryDataContext class. 

The parameters (which could be reordered to make better sense) read: the data is new or has changed, so store the results in “CurrentGallery” and return them to ‘lv’ (the ListView object on the web form).  Fetch the data with GetWebFiles from the instance of db (the WebGalleryDataContext object instanciated previously in the page).

Downfall #1: Methods are still required—you cannot pass a simple data source to the BindDataControl method.

Downfall #2: Additional coding on the BindDataControl methods required to handle parameters.

This third attempt handles our most complex request—but what about the original “hello”/”world” array request?  It can be done, but, as previously mentioned, requires extracting the array list outside of the method constructor.

 

protected void Page_Load(object sender, EventArgs e)

{

var gv = new GridView();

       this.Page.Controls.Add(gv);

 

BindDataControl<GridView, ArrayList, Page>(

true, “junk”, gv, “Get”, this.Page);    

}

 

protected ArrayList Get()

{

return new ArrayList {“hello”, “world”};

}

To reference methods that exist in the same code-behind page, this.Page and the Page class offer the correct class access.

So, is this the best way to do it?  Probably not!  How would you tidy this up or rewrite it?  I’m interested!





Exploring the ASP.NET MVC Preview 2 - Tests and Mocks

21 03 2008

The changes made around testing and mocking are a big step in the right direction from Preview 1. 

Mocking Controller Tests

In Preview 1, it was more common to create subclass testers for each Controller object—a very time consuming tasks.  Mocks “worked”—but, honest, just acted a bit odd.  Our ViewEngine still requires faking out, but Moq helps us along with the rest.

To start off, we’ll “Moq” up a Contact view and get the test to fail, then fix it (aka: implement it) to pass the test.

[TestMethod]

public void Contact_ReturnsContactView()

{

// Create a Moq instance of our HomeController.

       var controller = new Mock<HomeController>();

 

       // Create an instance of our FakeViewEngine.

       // There has got to be a way to do this without

       // ‘faking’ it. :(

var fakeViewEngine = new ViewHelper.FakeViewEngine();

 

       // Set the ViewEngine of our mock object to the fakeViewEngine.

       controller.Object.ViewEngine = fakeViewEngine;

 

       // Using the extension method from the MvcMockHelpers class,

       // set the controller context.

       controller.Object.SetFakeControllerContext();

 

       // Invoke the “Index” method.

       controller.Object.Contact();

 

       // Assert that Index() actually returned a view named Index.

       Assert.AreEqual(

              “Contact”,

             fakeViewEngine.ViewContext.ViewName);

}

This is part of the unit testing I still don’t like—that FakeViewEngine class.  The class consists of a ViewContext and get/set properties because, by default, IViewEngine can only RenderData()—it doesn’t allow direct access to the ViewContext. 

I suppose you could override IViewEngine and implement your own—but, for testability, is there harm in exposing those as read-only?

At this point, our Contact() method call is invalid (as it doesn’t exist in the HomeController class.

For now, so our test will run, we’ll add in an empty method to the HomeController class.

public void Contact()

{

           

}

Now, we can run the test.  As expected, it fails because the object (the ViewPage) doesn’t exist yet.

Test method Contact_ReturnsContactView threw exception:  System.NullReferenceException: Object reference not set to an instance of an object..

Now, to set off to resolve the error. 

Note: The templates are very precise.  This is a content page (linked to a master page) and a view page rendering the view of a MVC controller.  Be sure to pick the right item template for your task.

In our Views > Home directory, we need to add a new MVC View Content Page item named Contact.

After the View page itself has been added, implement the RenderView method in the HomeController class by modifying the empty method added earlier.

public void Contact()

{

RenderView(“Contact”);      

}

Now, rerun our test!

Testing Routes

There isn’t any mocking (yet) in our Route tests; however, we do use some of the helper methods Scott Hanselman wrote about and that I prepackaged up (see First Glance post for downloads).  I’ve created two quick and simple tests:

  • Does RegisterRoutes work successfully register routes to the RouteTable?
  • Does the Default.aspx mapping work at the root?

Before we get started, the tests require a simple TestInitialize (or SetUp, depending on your testing tool) to initialize the RouteCollection object.

private RouteCollection routes;

 

[TestInitialize()]

public void TestInitialize()

{

routes = new RouteCollection();

}

RegisterRoutes()

Our RegisterRoutes test method is extremely easy:

[TestMethod]

public void RoutesRegistered()

{

Assert.IsTrue(routes.Count == 0);

RouteManager.RegisterRoutes(routes);

Assert.IsTrue(routes.Count > 0);