MVC Not the Magic Bullet

by Admin 1. July 2012 08:31

I have been working with ASP.MVC 3 fairly heavily for the past year and I am anxiously awaiting the production release of VS 11 and MVC 4.0.  I think ASP.MVC  is a fantastic platform and solves many of the issues that exist with ASP.Net webforms.  The issue that I have notice though is many people in the development community are touting it as a “Magic Bullet” of sorts.  I have heard “Development times will shrink when we move to MVC” or “This would be so much easier in MVC” or “You won’t have to worry about page bloat in MVC.”  These comments are really only half truths.  

Will development time speed up under MVC?  In the long run with competent architects, developers and designers timelines should shrink a small amount (I need more data to give exact numbers) in MVC. Developers can spend their time writing business logic without having worry about the impact to the UI (with some considerations).  Designers can focus on making the UI look good without worrying about to much ASP gobbledygook (with some considerations). In addition SEO competent designers will have a much easier time adding SEO compliance to the site (if that is your goal).

Will development get easier in MVC? Yes and no.  I would like to discuss this particular topic in three parts. First, there are many seasoned ASP.NET Web Form developers out there that are well versed in the page life cycle, web controls and the ins and outs of ASP.NET in general, and can deliver excellent web sites working in that framework.  MVC (razor in particular) will be a complete paradigm shift for them.  I have heard several developers compare it to classic ASP and they are a bit annoyed they are being pushed back in that direction.  This could not be further from the truth, but a cursory glance at MVC (especially non-razor) it is easy to see how you could jump to that conclusion.  The removal of view-state and control-state presents a new set of challenges when working with pages.  The heavy dependency on JavaScript and JQuery on validations, AJAX and UI will be a bit of a learning curve for web developers that have only had to deal with that on a cursory level.  It is now, in my opinion, impossible to keep developers shielded from JavaScript and to a point even CSS.  Most developers are already comfortable in these areas but I know of several that only use the two when absolutely necessary.

Secondly, MVC (and HTML 5) blurs the lines between behavior, formatting and content which traditionally follows this model:

Web Block

The new model looks something like this:

Web Venn

Leading to questions of what should I use and when?  There really is no hard and fast answer to that question.  I usually use the following as a guide line in order of importance?  

Target Browser Compatible > Robustness of Functionality > Ease of Implementation > Maintainability

This wasn’t as much of a concern in ASP.NET Webforms as many of the web controls used handled all three aspects in their server side properties.  Which brings me to my third topic; the lack of standardized custom controls with ASP.NET MVC.  With ASP.NET MVC there is no such beast as a “Web Control”, there are only HTML helpers, JavaScript and JQuery libraries.  The big component players (Telerik, Infragistics and ComponentOne) are providing some JQuery libraries and MVC libraries but not much that competes with the free items already out there also JQuery changes so often that using version based component specific JavaScript and CSS really limits your ability to keep up to date.  I found out the hard way trying to go with the old model of “buy rather than build” can severely limit your options.  Recently I have been going the way of “find and tweak rather than build from scratch.”  GitHub and CodePlex are becoming the new source of third party components.  These controls however are purely an implementation of HTML, JavaScript/JQuery and CSS.  They are not server code specific.  So throw out the idea of setting some properties in the designer and it just working.

Lastly, can developers be completely oblivious to page bloat?  Absolutely not, page bloat has just shifted from viewstate to JavaScript includes and CSS.  Finding all of the controls to replace existing libraries comes with the price of including more and more .JS files.  So if you think you are trading you 500k viewstate for 0k MVC, guess again.  If you are not careful it could be 500k viewstate for 1 meg of added script.  Luckily MVC 4 is working on combatting that issue with bundling, but that isn’t a magic bullet either.

The long and short; if you were slashing timelines and removing servers from you web farms because you thought all of your problems were solved.  You are gonna find yourself up “bit” creek without a paddle.


Tags: , , ,

ASP.NET | CodePlex | GitHub | HTML5 | MVC3

The myth of String.Format in .net

by Admin 15. April 2012 07:44

Recently I was talking to a colleague of mine and the subject of string concatenation came up.  Now it is well known that for large string concatenation you should always use the StringBuilder object as it performs better than string concatenation.  But we were talking on a more micro level.  What is better for creating small strings String.Format or string concatenation?  I had run into the problem in the past and I knew string concatenation out performs String.Format hands down, but prior to that I was under the illusion Sting.Format was more efficient.  When I found out my colleague was under the same misconception I decided to write this article.

This article is not saying do not use String.Format.  Sometimes readability and maintainability outweigh small performance gains. Also, for formatting Dates, Times, Numbers, etc…  it is still the best choice.   However if you need to create thousands of small strings (Address concatenation, First Name Last Name, etc.) this may prove to be an eye opener.

So let’s look at the numbers for small string concatenation.  (These numbers are running on my machine your results may vary.)

Creating multiple single strings:

Creating 10000 separate sentences with string format.
Constructed Data: The quick, brown fox jumped over the lazy dog.
Elapsed Time: 00:00:00.0083951
Creating 10000 separate sentences with string concatenation.
Constructed Data: The quick, brown fox, jumped over the lazy dog.
Elapsed Time: 00:00:00.0000320
Creating 10000  separate sentences  with string builder.
Constructed Data: The quick, brown fox, jumped over the lazy dog.
Elapsed Time: 00:00:00.0011135

Obviously the clear winner here is string concatenation only taking .3 milliseconds.  But look at the difference between String.Format and StringBuilder.  Even with the cost of object creation in the string builder it is 754% faster than String.Format, huh…

Now let’s look at creating large strings:

Creating a 10000 string paragraph with string format.
Constructed Data: The quick, brown fox jumped over the lazy dog.  The quick, brown fox jumped over the lazy dog.  The ...
Elapsed Time: 00:00:05.2135822
Creating a 10000 string paragraph with string concatenation.
Constructed Data: The quick, brown fox, jumped over the lazy dog.  The quick, brown fox, jumped over the lazy dog.  Th...
Elapsed Time: 00:00:02.5202178
Creating a 10000 string paragraph with string builder.
Constructed Data: The quick, brown fox, jumped over the lazy dog.  The quick, brown fox, jumped over the lazy dog.  Th...
Elapsed Time: 00:00:00.0012484

This is where StringBuilder really shines.  There is no difference between creating a large concatenated string and 10000 small strings (results may vary slightly). However, String.Format is still the clear loser taking 207 % longer to complete then string concatenation.  This is when I decided it was time to find out why; ILSpy to the rescue.  I looked at the String.Format definition in mscorlib:

public static string Format(IFormatProvider provider, string format, params object[] args)
	if (format == null || args == null)
		throw new ArgumentNullException((format == null) ? "format" : "args");
	StringBuilder stringBuilder = new StringBuilder(format.Length + args.Length * 8);
	stringBuilder.AppendFormat(provider, format, args);
	return stringBuilder.ToString();

WHAT THE HECK !?!?!?!?!  Every time I call string format a new string builder is created?  That is crazy…  But there you have it, code doesn’t lie.

So the next time you are thinking "I’ll use String.Format for performance reasons," think again.

Try it for yourself: (26.73 kb)

Tags: ,

CLR | Performance

Metrics That Matter

by Admin 9. April 2012 14:07

Recently a member of a group of which I am enrolled posted a question, “How many lines of bug free code can a seasoned developer write in a day?”  This question tends to get the hackles of most developers to stand straight up (I am no exception).  But why do we become so offended by this question?  What has made this question a general taboo in the development community?  

I took some time to think about it and my thoughts turned to my grandfather.  He was a machinist for GE for 40+ years and his job was to work a 10-40 ton press and manufacture parts for various GE products.  He was a skilled laborer and I am under no delusions I could perform his job, however, he made the same part over the duration of his day.  His performance was measured by the number of parts he crafted minus the number of defective parts he created.  In machining this is a standard metric and one that is very easy to equate to the profit vs. expenses.

Trying to fit development into the same bucket is impossible.  We are not creating the same exact piece of code each day.  Equating average lines of code to throughput is analogous to judging the quality of a book based on the number of pages.  “If Book A has 200 pages and Book B has 400 pages, then obviously Book B is twice as good.”  Not really a metric used by most publishing houses.

But we are still left with the question, “what are good metrics for determining the effectiveness of a developer?”  For my projects I usually subscribe to the agile method of software development.  There are clear metrics for determining the success of a project and the effectiveness of a developer.

  • The team determines their low and high end effort/story points (most effort points are loosely based on the Fibonacci sequence 1, 2,3,5,8, 13, 20, 40, 100 and infinity).  An example of a 1 would be a label change, where as a 20 would be the creation of a workflow service to guide users through an application.
  • User Stories (feature requests) are examined and converted into effort points (this is usually done by consensus.)    40 and greater usually become “epics” and are broken down into smaller user stories.
  • User stories are added to a “Sprint” based on the number of effort points allowed in that given sprint (velocity). Example: Sprint 1 takes 2 weeks and has a maximum velocity of 100 points 
  • User stories are then converted to tasks in a sprint meeting. 
  • Tasks are given a duration and assigned to users.

After just a few sprints patterns start to emerge.  Effort points and durations start to have a clear correlation.  Based on this, management reports can be created that clearly show star developers vs developers that may need extra help from the more seasoned developers.

This type of metric does not implement a draconian policy of you need to write x number of characters today to get your food pellet.   But rewards developers for innovation and coming up with the best solution to a problem in a time-boxed situation.



Agile | SDLC | Project Management

Dynamic Data: Skeptic Turned Believer

by Admin 9. April 2012 12:35

I have to admit for the most part I loathe code generation tools.  The code generated is, in most cases, unsupportable, messy, uncommented and not optimized.  But that is the nature of code generators (otherwise most of us wouldn’t have jobs).  Recently I wrote an application that requires an administration piece for some of our database administrators.  Being technical people they do not need all of the bells and whistles of your average user.  I normally try to avoid these types of applications; they are not sexy, tedious and consume more time to develop then it appears they should.  

I had heard of Dynamic Data Web sites about 3 years ago and dismissed them as another code generation nightmare, however, in preparing for my Microsoft Web exam I ran across them again. I realized they are not code generated web sites, they are, in fact, a template with data hookups allowing developers to create a quick standard CRUD (Create, Read, Update and Delete) web site with a simple grid/detail page interface.  After looking into the details of how to implement, develop and configure the application I realized Dynamic Data is a perfect candidate for quickly implementing the application development task I had at hand.

There is a simple checklist I came up with to determine if an application is a good candidate for an out of the box (mostly) dynamic data implementation:

1.Are a relatively low number of users going to be accessing the application?

2.Can the application be created with a relatively simple UI

3.Is the application used for mainly administration (user creation/modification, updating type tables, updating contacts, etc.?

4.Is this not a user facing application?

5.There are no business requirements for the application

If the answers to all of those questions are yes, there is no reason not to create a dynamic data web site.  I would go into the details of how to create a Dynamic Data Website but Visual Studio 2010 makes it so easy I would just be regurgitating the steps provided for you.  I will say this, give it a try with one of your existing databases and you will see just how easy it is to create a fully functional application in minutes.

Tags: , ,

ASP.NET | Entity Framework | Dynamic Data


<<  June 2017  >>

View posts in large calendar

Page List