Monthly Archives: June 2008

Switching to BlogEngine.NET

You may have noticed that things look a little different around here.  I finally got fed up with the themes in dasBlog.  The CSS in many of them was just plain bad, with fields overlapping each other and content scrolling off the screen when it shouldn’t.  I know theming seems like kind of a small thing to switch blog engines over, but really, the look and feel of your website can say a lot about your professionalism, so I felt it was worth it to find something I was happy with.

I looked at several different engines before deciding on BlogEngine.NET.  WordPress is very popular, and can be made to look very nice, but my site is hosted on Windows, and from what I read WordPress needs to run on Linux.  I also looked at GraffitiCMS, which was very nice, and much easier to set up than other CMSes I’ve worked with before.  Although blogging is possible with it, it seems a little more general-purpose than I was looking for. 

I watched a how-to video on setting up BlogEngine.NET, and looked fairly lightweight and easy to set up. I also liked the variety of acceptably clean-looking themes.  The clincher for me though, was this post by Merill Fernando talking about exporting his dasBlog setup to blogML and being able to import it right into BlogEngine.NET.  He even wrote a nice little GUI front-end to handle the export from dasBlog.  The whole process was pretty painless, and I didn’t lose my old posts.

I also picked up the nice DarkBlog theme created by Ruslan Tur, but changed the stylesheets to use blue text instead of green.  I’m pretty happy with the result, and I’d recommend BlogEngine.NET to anyone looking for an engine.  Your thoughts on the change are welcome!

Where’s the Real Reuse in ASP.NET MVC?

Just a quick note here.  I was playing around with ASP.NET MVC today, and I got to thinking, how does one encapsulate both behavior and markup (a la UserControls in WebForms) when using MVC?  Well, there’s a thing called a ViewUserControl that you can use in your ViewPages, but all that really does is encapsulate the markup and rendering.  You’d use them like this:

MyViewUserControl.ascx

And then you would call it from the ViewPage:

MyViewPage.aspx

If you use a typed ViewUserControl, you can feed the object to the RenderUserControl method as an additional parameter rather than going to the ViewData collection, but that’s not what gets to me.

The controller that renders MyViewPage.aspx is still responsible for retrieving all the data that MyViewUserControl.ascx uses. So, everywhere that I want to display that list of sponsors, I have to remember to write the code to go get it. That’s not really reuse, is it?

There was a comment on Rob Conery’s blog back in January that I ran across that suggested something like this:

That way, there can be one controller that’s responsible for pulling that Sponsor data from the data access layer. I’m not sure if this is possible; I’m not familiar enough with the way MVC works to know if a second (or third, or nth) controller can be created and called once the main controller has started rendering MyViewPage. From an end-user perspective, something like that would be great, since it would let us truly encapsulate every aspect of what that ViewUserControl is about. Here’s hoping!

Sprocs? Really?

I’ve been studying for my first SQL Server certification (70-431, if you’re curious).  I read the chapter today on “Implementing Stored Procedures.”  As I was reading, the following passage got my attention:

The permission delegation possible with stored procedures provides a powerful security mechanism within SQL Server.  If all data access – insertions, deletions, updates, or selects – were performed through stored procedures, users could not directly access any table in the database.  Only by executing the stored procedures would users be able to perform the actions necessary to manage the database.  And although users would have the permissions delegated through the stored procedures, they would still be bound to the code within the stored procedure…

How is this in any way desirable?  Who are you actually trying to keep the real data away from?  The only answer that is obvious to me is developers.  The author seems to be describing some personal utopia, where no childish developers could destroy what the mighty DBA hath wrought.

He says in an earlier section, “Even more important, stored procedures hide the structure of a database from a user…”  Hide the structure of the database?  Again, why?  How could developers make informed decisions about creating data access layers if they don’t even know what tables the data is on?

The author also says that using stored procedures lets you “…isolate database code for easy maintenance instead of requiring you to find hard-coded SQL statements throughout an application if you need to make changes.”  A worthy goal, certainly, but is the answer really to put the executable code in the database?  I would think that a well-crafted data access layer would do a much better job of this.  Conventional languages offer much more flexible language environments, and code changes are tracked by source control.  You can put stored procedure definitions in source control, but it’s in no way integrated into SQL Server.  It’s basically the same developer experience as checking in some unrelated text file to some arbitrary directory in your tree, which has has no real bearing on what’s actually running in the DB at the moment.

I’ve heard people talk about the database-centered approach espoused by MS, but this really makes it clear.  It’s as if the author feels that the best application would be one with as little application code as possible, basically a thin veneer over a relational database.  Since I’ve worked for the first three years of my career in a shop that used DB2 (with absolutely no stored procedures), I guess I haven’t even been offered this particular flavor of Microsoft Kool-Aid until now.  If this has been the Redmond gospel for a while, I can see why using OR mappers must feel like such as breath of fresh air to some people.

For what it’s worth, I’m planning on using ASP.NET MVC with Castle’s ActiveRecord for my next pet project, a little site I’m putting together for my mom’s fiancee.  I’ll be sure to record my impressions of that story.