>Today is the last day for six co-workers of mine, five from my IT team.  I’m very sorry to see them go but business is what business is. I wish them all the best.

Deployed First ASP.NET MVC Application

Last week, I deployed my first ASP.NET MVC application at work.  Besides being our first ASP.NET MVC app, it is also the first app where we are testing for multiple browsers; IE7 (using IE8 emulation), IE8, Firefox and Chrome.  And that has taught me a number of things to watch for between the browsers.  The most recent item to catch me was a difference between IE and Firefox in handling “empty” nodes.

If you have a div named “node” and you have the opening and closing tags on separate lines, the jquery statement $(‘#node’).html() will return different results in different browsers.  IE returns an empty string  while Firefox and Chrome return the carriage return and any spaces that might be present.  Since I was checking for an empty string to trigger some processing, it wasn’t working in anything but IE.  Putting the open and close tags for the div next to each other fixed Firefox and Chrome.

I get why Firefox didn’t work.  In fact, I would argue that Firefox & Chrome worked correctly and that IE should not have worked.  My point is that just because you test and have the site working, it doesn’t mean the site works.  If you want true cross-browser compatibility, all web interface tests have to be run against all browsers.

And that begets the real problem.  How do you figure out what browsers and what versions to test?  The list will get very big very quickly and that gets expensive.  While unit tests will help with some of this, they do have limits when it gets to exercising the interface through multiple browsers unless you buy some very expensive tools.  And that’s before even considering the problem of multiple versions of IE or Firefox running side-by-side.

It shouldn’t be this hard to build an “ajaxy” web site that is compatible with the major browsers.

>Mongo – Continued One More Time

>So I’ve done some research and my fears are correct.  In order for me to use an ISP with Mongo, I’d have to get a virtual server.  And, the cheaper virtual servers are out because those won’t let you install software. 

This means Mongo has become a fun experiment for now and it’s back to SQL Server I go.  I will have to remember to look into Mongo and the other non-SQL database options again in a few months to see how things have changed.

>Mongo, Cont’d

>So I’ve been playing with Mongo and I’ve got a nice generic wrapper to convert objects to Mongo Documents and visa versa.  It works pretty well and performance continues to be very good.

And I’ve got an idea for a site that I think will work very well with a Mongo back end.  I am a little concerned about using Mongo though; hosting could be an issue.  I know a virtual server/host would work well but those aren’t as cheap as “standard” ASP.NET hosting.  And since I don’t think my site idea would generate much money (except in my dreams 😉 ), an expensive virtual server is something I’d rather not do.

So now I’m trying to decide if I go forward with Mongo or if I fall back to SQL Server for this site idea.  Oi.


>I’ve started to look at some of the NoSQL databases that are being talked about a lot.  I decided to start by playing with Mongo, using the c# driver posted by samus (Mongo c# driver) on github.

So far, it’s pretty interesting.  I’ve done some basic performance testing and it is pretty fast; seemingly better than the SQL Server I’m used to.  And that’s with no performance work and not worrying about it.  Granted by databases aren’t big yet but still.  For it to be fast with me not understanding the product that fully yet is pretty good.

Plus, creating databases and collections in the store is easy.  You just reference them and they are created.  I wish SQL Server had a way of letting the request create the data.  That would  be a nice feature to add though I can just imaging the number of problems that would create in performance and data management.

I do wish the driver would take either a JSON formatted string to populate the document or that it would use reflection to populate the document.  And then do the opposite to get the database stuff back into the model. Ah well, I know what I’ll be working on next with this.


>I’ve started creating my first ASP.NET MVC project and I have to say, I’m enjoying it quite a bit.  The ease with which you can work in testing and the power built in are pretty cool features.  And, having the jquery “built-in” is nice. 

I’d say my favorite features are:

  1. Not having the page bloat you get with web forms and view state.
  2. Not having the complications of adding fancy “ajaxy” features if you don’t want to use the overhead of update panels.
  3. Not having to deal with the headaches of View State and Ajax is really nice.

I’m impressed how easy it was to pick up and how some of the features were implemented.  I really like the way that did the data binding to the models.  It’s easily customized but works well right-out of the box.  And, adding things like the MS AntiXSS library to help prevent cross site scripting attacks is sweet.  And since I’ve been doing a lot of CSS based design previously, formatting the pages is not any more of a challenge than it was with web forms.