This project is read-only.


Aug 12, 2008 at 1:30 PM
I've had a look at the code.

The approach of starting with the Atom spec is interesting, since it means that you won't have a mismatch when it comes to serving atom data.
However it makes the back-end more daunting, since it all has to be in place at once.
You have public class FileAtomPubProvider : AtomPubProvider as the only provider at present.
In a more mature versions there would ideally also be a SQL database-backed provider, and a mock provider for testing?

AtomPubProvider is from ProviderBase. I'm not that familar with the  ProviderBase class - I would have expected AtomPubProvider to be an interface - which seems to be what all Dependency Injection and IOC tools expect. What benefits does this base class give?

Aug 13, 2008 at 5:52 AM
Edited Aug 13, 2008 at 5:55 AM
I'm excited about using the Atom spec as a basis for BlogSvc.  It allows other tools to work with it automatically (Live Writer).  Can you explain what you mean when you say
However it makes the back-end more daunting, since it all has to be in place at once.
One nice thing with Atom (and .NET 3.5) is that I can easily reuse the controls and layouts for all sorts of existing data on the internet. For example, I am using the RSS feed for this discussion by way of the SyndicationFeedFormatter in a sidebar on

I'm using the provider design pattern because it is so well understood with the providers that have been around for years. If this design pattern is outdated then I need to read up on these newer patterns.
Please see ASP.NET 2.0 Provider Model: Introduction to the Provider Model
A couple pages down explains the ProviderBase.  I'll definitely look into the newer MVC membership provider usage to see if there is a better way.

Also, yes, there will be a SQL database-backed provider.  A mock provider for testing is also a good idea.
Aug 13, 2008 at 9:35 AM
Edited Aug 13, 2008 at 9:36 AM
What I meant by that was that the other blog projects are iterating outwards, starting with just a few  tables and working through those from front to back before adding new ones. With the atom spec there on day one, your database provider has to provide lots of different data items just to get started.

But I suppose you could stub most of them out and implement the methods iteratively.

The use of interfaces to isolate and mock data layers is shown in the mvc storefront video series:
See also

I'm sure that the provider base class also has benefits, I'd have to read more to asses what they are.

Aug 13, 2008 at 6:01 PM
Edited Aug 13, 2008 at 6:03 PM
Yes, it is true there are more data items (by a factor of 3).  However the complexity hasn't increased all that much and it is much more generic than having a BlogPost table and BlogComment table etc.  There is a need for around 12 tables.  See Design for a diagram of the object model.
Aug 17, 2008 at 6:30 AM
Anthony, although I had previously watched the OpenID video of the storefront series (part 16), I had yet to watch the rest.  Thanks to your post above, my development came to a halt on Thursday and I watched every episode.  Now, I'm taking a hard look at switching from the provider model to the repository and service structure (with IoC) as I feel it would fit nicely.  And, I had just hit a point where the provider model just wasn't working well with the design as it was causing me to refactor too much.  So I'm going to give some of the these techniques a try.