I've been playing with ways to write a solid (and even SOLID :)) architecture with ASP.NET MVC. I started with a plain LINQ to SQL approach, and then migrated to LightSpeed, and finally ended up checking out S#arp last week. Here are my notes of pros/cons on each approach. Yes, I could (and most likely will) address some concerns by writing code for it. This is more of a laundry list of the state of things as I see them at this point in time. LINQ to SQL Pros Cons - MS is talking about phasing LINQ to SQL out and forcing people towards Entity Framework. I'm pretty sick of chasing MS's data-access strategies around every year.
- LINQ to SQL mostly defaults you to a 1:1 mapping between your database and your model.
- Support for modifications to the schema sucks, to be generous.
- No UnitOfWork concept. Of course, as I prepared this blog entry, I found this article published just today, so maybe that would address this point.
LightSpeed Pros - Support is outstanding.
- Nightly builds are available.
- Visual designer.
- Proven patterns bundled in their core libraries (UnitOfWork, Repository, Entity, etc.).
- Picks up changes from the schema flawlessly.
Cons - Commercial and propietary.
- Lacks quite a bit of LINQ support. For example, groupby and join are not supported. This meant that I use LINQ to SQL when I need these features. Fortunately, that's all isolated to my report module, so it's not as horrible as it could be.
S#arp Pros - Open Source
- Uses standard, widely adopted open source libraries: NHibernate, Windsor, etc.
- Convention over Configuration
- Scaffolding
Cons - I'm not digging the T4 templating mechanism. They conflict with VisualSVN and Developer Express tools, and having to write a template for each and every entity is cumbersome.
- No visual designer
- No ability to import entities from an existing database. Yes, they like DDD, but in almost every project I've been a part of, the database is the thing that already exists.
- No UnitOfWork pattern (I might be able to fit code out there that does this in with S#arp). The [Transaction] attribute approach feels a bit dirty.
- The scaffolding is a bit too simple. It doesn't build up object graphs with links (for display) or SelectLists (for editing). Yes, I can add that. It probably will get that functionality at some point, too. But it doesn't do it right now.
For now, I think I'll be staying with LightSpeed, but I'll be watching S#arp very carefully.
Ages ago, I wrote about my search for a file sharing application. I eventually went with BeInSync, and used it quite a bit over the past 18 months or so. However, they haven't updated it recently, and there are problems when editing Excel spreadsheets inside the shared folder (I told BeInSync about this problem, they fixed it, and then broke it in the last release). All in all, it was just showing it's age. Armed with a new set of fairly light requirements (Mac/Windows support, permissions, auto-sync that doesn't fail), I evaluated the space again and came out with a very positive experience of DropBox. It works very well between Mac and Windows, has an awesome web interface, and hasn't exhibited any lags or slowness. In addition, it has the ability to revert to previous versions of documents, which is a nice feature that all developers have come to appreciate. I'd like to see a couple features in the near future (native iPhone app with support for iWork documents, ability to set your own private key), but this thing was dead simple to install and use, and has worked brilliantly for the past month with a small group of people.
I'm using SqlBulkCopy to quickly copy an Excel spreadsheet into MSSQL. It is lightning fast, and works extremely well. One snag came up because I need to have an Identity field for my primary key on this newly copied table (the short story is NHibernate's need for a PK, and the lack of anything resembling a PK in the Excel data due to it coming from legacy data). The problem is if you add the Identity field in the first column of the destination table, SqlBulkCopy will try to line the columns up by position and things break. You can add ColumnMappings to have SqlBulkCopy write the excel columns to the right MSSQL table column, but that can be a lot of code if you have a lot of columns. My solution ended up being to simply add the Identity field to the end of the destination table. By doing that, the columns line up during the SqlBulkCopy and everything works just fine.
At work, a debate broke out over MVC. In that debate, Chris Peterson commented that he hated the way things looked on the view pages, specifically with code executing in the view context. By way of example, he talked about the need for a for loop to display a collection, and how he didn't like that. Geoff Lane commented that Grails had support for this built-in. To overcome these objections, I wrote the following simple extension method: public static class RenderPartialCollectionExtension { public static void RenderPartialCollection<T>(this HtmlHelper htmlHelper, string partialViewName, IList<T> list) { foreach (T item in list) { htmlHelper.RenderPartial(partialViewName, item); } } } This means that instead of the old-style View page code, like this: <% foreach (Foo foo in Model) { Html.RenderPartial("~/Partials/DisplayFoo.aspx", foo); } %> You can just write code like this: <% Html.RenderPartialCollection<Foo>("~/Partials/DisplayFoo.aspx", Model); %>
It seems that ASP.NET MVC doesn't allow for strongly-typed partial views. If anyone knows of a clean way to do it, I'd love to know! Take the following typical page declaration:
<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<Foo>" %>
This declaration allows us to access the Foo.Bar property in the view page using the following syntax: Model.Bar. This works really well, and we even get Intellisense for Foo when accessing the Model property in the editor. In contrast, if we inherited from the non-generic ViewPage, Model becomes a simple object type, which means type-casting to get to our passed in model object.
However, using partial pages with a similar technique does not work. For example, if we have a partial page (ViewPage or ViewUserControl) and call it like below, it will not allow for strong typing of the page: Html.RenderPartial("DisplayFoo", foo)
If we try to strongly type the page, it will result in an error like this at run-time:
Parser Error Message: Could not load type 'System.Web.Mvc.ViewPage'.
One work-around is to create a code-behind file, and specify the strong typing there, and then inherit the partial page from the code-behind. But I really don't like that. RC1 made great strides to get rid of the code-behind mess, and I would prefer not to reintroduce it just for this.
Update: Thanks to bradleylandis in the ASP.NET MVC forum, he correctly figured out that I had my partial page in a folder other than the Views folder. He mentioned that you need to copy the web.config file from the Views folder to any folder that you serve view pages out of. After doing that, I now have a strongly typed partial page.
There were a few changes between ASP.NET MVC Beta and RC1 regarding list binding. For background on list binding, look at Phil Haack's excellent article. Here are the changes that I saw, some good, and some bad: - You no longer need to specify the ".index" hidden field. This is good, as it's one less hidden field to take care of.
- Binding occurs automatically for lists of complex types, but you must have contiguous numbering of the elements, starting with zero. This means that you can no longer specify the index with things like key information. I'm not wild about this change.
- In the Beta release, binding would only occur for properties of IList. I've been using LightSpeed lately, and that means my property looks like this: EntityCollection<FooType> FooProperty. EntityCollection supports IList, but because it wasn't truly an IList in the class declaration, the default binding didn't work. In the Beta release, I got around this by adding a mirrored property of IList<FooType> and then copying the data over to FooProperty in my controller method.
- Nested property references, e.g. Foo.Bar, now get the resulting input id renamed to Foo_Bar. This makes it easier to work with jQuery selectors on these elements.
All in all, I'm really liking the RC1 release. I'm looking forward to the release!
I'll be out in L.A. for PDC 10/25-10/30. If you're going to be there, too, drop me an email!
Please RSVP to dmiser@wi.rr.com ASAP if you plan on making this Wednesday's ALT.NET meeting, where we can hopefully cover mocking. When: 10/1/08 @ 7pm Where: 10000 Innovation Drive, Suite 260 (SpiderLogic office)
Due to lack of responses, I'm canceling the ALT.NET meeting for tonight. Please mark your calendars for Wednesday, 10/1/08 for the next meeting, where we will try to cover mocking. Please send me an email at dmiser@distribucon.com if you plan on making it in October.
|