FreeSNAP, Day 2: And then there was CodePlex

This morning on the train I made some pretty decent progress, and found some great new tools as well that may help with (what I hope will be) the less important parts of this effort!

Let’s go through a brief overview of the tasks of the day, including creating the naive first pass at the model, examining Scaffolding and Persistence options, and performing the initial post to CodePlex of progress thus far.

Let’s make a project!

On the 21st, before I even truly decided that I was going to go ahead and actually do this (I happened to be bored on the train and started thinking about FreeSNAP again), I went ahead and made an empty MVC project for the purpose: though it happened several days ago, for the sake of giving complete coverage I’ll cover it briefly now.

I started off the project by opening up Visual Studio 2010, choosing to make a new MVC 3 project, and letting it generate the basic authentication framework and style for me: I don’t really care what authentication we’re using right now, and I certainly don’t care about how these pages are going to look yet.  There it sat, dormant, until this morning.

Building up the Model

Once I got on the train, I decided to lead off by just building up a naive data-only set of models that represented the various entities in the Atom protocols.  By the time the train made it to Haverhill, I had identified and fleshed out the major entities defined in the protocol: Service, Workspace, Collection, Generator, Category, Feed, Entry, Link, and Person (roughly in descending order down the aggregate tree).

(Figure 1: A very quick sketch of the model from memory… (A) is a model but not an Entity because it’s really a transient representation of data, (B) are singleton and thus should probably just be settings accessible from somewhere, and (C) are probably Entities but I’m going to withhold judgement on them… particularly Links, which feel like they wouldn’t have the kind of reuse that I’d like to see for something that’s a first order Entity)

Going through the specs, I made some naive decisions about what should be left open-ended and what could be contained in enumerations, and I also added some model attributes as I thought of it (though I have to go over it again to fill in more details), knowing that any Views I generated would need to know at least basic attribute information about the properties of the objects in order to give reasonable content representations.

At first, I didn’t give any concern at all to how these objects would be persisted: they had aggregate relationships but no Ids other than those required in the Atom spec, and no constructs meant for storage purposes.  They’re essentially almost POCOs: they’re plain old C# Objects, but with attributes for scaffolding purposes.

Whatever persistence mechanism I end up using, I know that I want to not much time thinking about what that mechanism is, and even less time worrying about satisfying its needs.  I figured that eventually I’d probably settle on the models being a front-facing facade for Subsonic, which is my personal ORM of choice for quick and fairly unobtrusive persistence, but I didn’t want to commit myself to it just yet.

Scaffolding and EFCodeFirst!

It was then that I began to search for something that could provide some basic scaffolding capabilities: I could generate views with the built in Visual Studio wizards, but I was interested in something that would really pop these out quickly and get them out of the way.

I found a gem in MVCScaffolding, a great emerging project that’s seeking to use T4 templates to provide Rails-like quick scaffolding of models.

Continuing on, I followed the instructions on the linked post to install the relevant packages and generate a quick Scaffolding and Repository for the Collection entity, and there I ran into only one obvious limitation that I had to concede for persistence purposes: my first order Entities needed to have database IDs.

I shrugged and added IDs to what I considered to be first order entities: Workspace, Collection, Entry, and Category.  For now, things like Links and even information about People isn’t something I want to worry about the persistence of right away… I’ll deal with choices related to these less obvious Entities later.

Service and Generator aren’t worth persisting at all: there will only be one Service per server, and the Generator will be a fixed identifier for the server’s software itself… I’m considering whether this kind of information should just be pulled from some configuration file and accessed as needed, but for now I’ll leave them as models.  I don’t feel like worrying too much about the dirty details of the models at the moment, and there’ll always be room to improve and modify these – especially these two models – at pretty much any point in the process.  Let’s just keep moving forward.

As I continued to read the MVCScaffolding article, I found out about an interesting and relatively recent development in the Entity Framework: the existence of the CodeFirst CTP.

My prior experience with Entity Framework was less than pleasant.  We were using the initial version of EF on a project at one of my previous jobs, and I wasn’t entirely pleased with it.  It felt bloated and got in the way of development.  At my next job, when we chose to use Subsonic instead, I leapt for joy at its ease of use and ability to get the hell out of my way: especially compared to the Entity Framework.

However, even with the few minute son the train that I got to play with EF CodeFirst, I saw that this was really a revolution in the Entity Framework.  It got out of my way effectively: in fact, even moreso than Subsonic.  I was able to, at least for my naive implementation, make my vision of coding the classes first and worrying about the specifics of persistence closer to a reality.  Time will tell if it will continue to stay out of my way, but I’ll stick with it as a persistence mechanism unless it proves itself too cumbersome.  So far it’s looking good: and MVCScaffolding actually generated a quaint little Repository that saved me a few minutes of time.  Nice!

(Figure 2, some new stuff in the project, including the generated Repo and Context which I feel a strong compulsion to move out of the Models folder… I’ll be doing that tomorrow for sure.)

Anyways, once I added Ids to various entities I gave generating the Controller and Views another shot.  This time it generated content, though underwhelming in nature: understandably so, as I’m going to need to do some tweaking to the templates if I want things like the details page of a Collection to actually show its constituent articles in a paged grid.  That would be the work of a much more robust T4 template, and at least MVCScaffolding gives the framework with which I can now make such a template and use it easily when the time comes.

At this point, I realized two things:

  1. It wasn’t really worth worrying about the scaffolding at all yet, interesting as it was and useful as it is to have it and know about it for when the time comes, and
  2. We were pulling into North Station.

I packed up and called it a day on the development front.

Posting to CodePlex

When I got home a couple hours ago, I went ahead and posted this first quick effort on a new CodePlex site and published it along with a brief description of the goals of the project.

It is now free to peruse as you wish, and will be as I continue this effort!  I’ll go ahead and make daily tags too corresponding to posts, so that we have snapshots of the evolution.

Lessons of the Day

I walk away with the following lessons:

  1. MvcScaffolding is a good starting point if you don’t care about UI in your project, or if you’re willing to tweak the templates to suit your needs
  2. EF CodeFirst shows real promise in a five minute glance at it: we’ll see how it holds up
  3. Proper prioritization is something I will continually have to strive for
  4. One can get a decent amount done on the train if they know the tasks at hand (all things considered, that wasn’t too bad of a job for a bit more than an hour of quick analysis and development work in a crowded environment)
  5. I need to figure out just what I ought to keep in the repo and what doesn’t need to be in there for stuff that was imported with NuGet.  I imagine that I shouldn’t need anything other than whatever’s included in the project itself in an ideal world… but Visual Studio isn’t always an ideal world.  Something to research tomorrow, before it gets out of hand!

Until tomorrow!

Get the source for this ongoing project at CodePlex now!  (See the “Day002″ tag for an archive of progress up to this article)

Share it with the world:
  • Print
  • Digg
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Reddit
  • RSS
  • Slashdot
  • StumbleUpon
  • Technorati
  • Twitter
  • DotNetKicks

About EdgarVerona

I'm into Programming, Poetry, Philosophy, and other things that begin with "P" (obviously, or it wouldn't fit!)
This entry was posted in Programming and tagged , , , , . Bookmark the permalink.

Comments are closed.