Lazycoder

31Aug/101

Why Rails and Django are successful.

How I would fix ASP.NET.
I agree with the idea of using real-world dogfooding to refine ASP.NET.

Disagree slightly about the reasons that Rails and Django are successful. They are successful not because they were written first by application developers, but because they were extracted from real-world applications. That is, the frameworks both grew organically as the appDevs saw the need rather than trying to anticipate the need. Both are also very opinionated in terms of convention over configuration.

The fact that ASP.NET MVC leaves a lot of the decisions up to the developer has been one of my criticisms of the framework since it was launched. It does mean that you can apply your own conventions to it, but you have to do a little more work. Work that, I believe, could be better spent working on the hardest part of the application.

Tagged as: , , 1 Comment
30Jun/1012

The hardest part of software development has nothing to do with code

People who complain about how much “more” code they have to write in an MVC project versus a Webforms project, or really any project, prove to me that they have absolutely no idea where the REAL work is in ANY development project.

The main work in any software development project is FIGURING OUT WHAT TO BUILD. How you build it is trivial compared to the amount of time and effort you SHOULD put into discovering the users needs and working with them to solve their problems and make their life better.

Remember, that’s the number one purpose for any piece of computer hardware or software. This cannot be stressed and repeated enough.

COMPUTERS SHOULD MAKE OUR LIVES BETTER!

How do we write programs that make lives better? By writing programs that fulfill their needs and ease the pain of their work. We still aren’t at a point where we have a common, easy to understand vocabulary when it comes to build software. We often get it wrong the first, second, and third times. That’s where the discipline and engineering comes into play.

Filed under: Agile, General, MVC, Tutorials 12 Comments
2Dec/094

Announcing Planet ASP.NET MVC

I’ve created a “Planet” type site that aggregates posts from different sources about the ASP.NET MVC Framework. Feel free to suggest new feeds you’d like to see on here. Content owners, I’ve made every effort to ensure proper attribution (e.g. the link here and the link in the feed point to the source of the post, author names are retained). However if you want your content removed from this feed, feel free to contact me with no hard feelings.

Mainly, it’s for my personal benefit. I wanted to have a single source for my ASP.NET MVC news but Google searches pulled in a bunch of “why MVC isn’t for me” type of posts, which I don’t really care about. Those people are just wrong. ;)

You can find it here. It may eventually get it’s own domain and a nifty theme.

Planet ASP.NET MVC

Filed under: MVC 4 Comments
18Mar/093

ASP.NET MVC Tip – Return specific views for specific errors.

Earlier I had said to keep your controllers as thin as possible, that doesn't mean that they should necessarily just be two, or one, lines of code.

Take an instance where you are retrieving items from a web service in your controller. Let's say that you get a 404 error and your service will throw an exception telling you that the service can't be found. Take a look at this controller action

PLAIN TEXT
CODE:
  1. public ViewResult Item(string itemID)
  2. {
  3.     Item item = MyWebServiceWrapper.GetItem(itemID);
  4.     return View("Item", item);
  5. }

As it stands this action is pretty thin, but if an exception is thrown the user will be presented with either whatever custom error page you have defined in your web.config or the dreaded Yellow Screen of Death.(YSOD). You can wrap the call in a try-catch block and catch the exception. But rather than creating a generic errors page that will display any raw exception message, it's a much better idea to return an error specific view to your user with a friendly error message.

PLAIN TEXT
CODE:
  1. public ViewResult Item(string itemID)
  2. {
  3.     try
  4.     {
  5.         Item item = MyWebServiceWrapper.GetItem(itemID);
  6.         return View("Item", item);
  7.     }
  8.     catch(ServiceCannotBeReachedException)
  9.     {
  10.         Item item = new Item(itemID);
  11.         return View("CannotRetrieveItem", item);
  12.     }
  13. }
  14.  
  15. //The CannotReachService view has a line that looks like this
  16. // "The item <%= Model.itemID %> can not be retrieved at this time. Please try again later"
  17. // obviously this can be globalized/localized as needed.

This leads to a much "dumber" view and is a much better idea than modifying the "Item" view to display errors if something isn't right with the model or passing in special error parameters to the view. Let the view deal with the data it is meant to display and nothing else.

Filed under: .NET, MVC, Tutorials, Web 3 Comments
17Mar/096

ASP.NET MVC tip – Don’t use the Content or Scripts directories for view specific files

ASP.NET MVC creates a default file structure for you when you create a new project. It includes a Scripts directory, which contains the MS AJAX and jQuery .js files, and a content directory, which contains a Master page and CSS files. I find this to be extremely cumbersome and it forces me to jump around a lot. Storing shared CSS and JavaScript files in those locations is fine in my opinion. But if you are using View specific CSS or JavaScript files, you should put them alongside your view page in the Views directory. This allows you to quickly find the file you want to work on.

Filed under: .NET, MVC, Tutorials, Web 6 Comments
16Mar/0910

ASP.NET MVC TIP – Keep your controllers and actions thin

When writing you controller actions, keep them short and sweet. Don't add a lot of actions and keep a close eye on the length of each action.
Whenever possible, I try to make my controller actions look something like this.

PLAIN TEXT
CODE:
  1. public ActionResult DoSomething()
  2. {
  3.     MyModel model = MyService.GetModel();
  4.     return View("MyView",model);
  5. }
  6. //or
  7. public ActionResult DoSomethingWithAKey(int myKey)
  8. {
  9.     MyModel model = MyService.GetModel(myKey);
  10.     return View("MyView",model);
  11. }

(1)

There are two reasons to do this:

1) It makes your controllers less complicated and easier to maintain. - You don't want to have to do a lot of debugging in your controllers. Chances are, if you have a lot of complicated logic in your controller actions, you are probably mixing concerns. Make sure that your controllers are only responsible for getting data from your models and figuring out what view to send to the client.

2) It makes testing easier. If all you are doing is getting a model and passing that model to a view, what do you really need to test? Maybe that the correct view is being returned.

(1) Of course I use more descriptive names than "myKey". :P

Filed under: .NET, MVC, Tutorials, Web 10 Comments
   

The Lounge

TwitterCounter

120x60-1

What I'm Doing...

Powered by Twitter Tools

Books I’ve worked on

Contributors

Links

Delicious  FriendFeed  Last.fm  LinkedIn  

RSS Herding Code Podcast