I've been thinking through the Provider model and it seems very
powerful. If we were to go this route I am thinking we would need the
following areas covered:
- Regular pages (pages displayed to the public)
- Membership Provider - has info on user, groups, profile, etc
- Site Provider - Has info on the site itself, defaults, etc
- Page Provider - Has page specific info, layout, master page to use, etc
- Content Provider - Provides content, is RSS based. If anything
special is needed in content then a new provider that is based on this one
is added to extend the RSS model appropriately.
- Site Admin Pages (pages to alter the site)
- Membership Provider - has info on user, groups, profile, etc
- Site Provider - Has info on the site itself, defaults, etc
- Page Provider - Has page specific info, layout, master page to use,
etc
- Web App Admin Pages (pages to alter site definitions)
- Site Provider - Has info on the site itself, defaults,
etc
On the data store side of the providers: One of the things I am trying
to accomplish is creating a little more seperation between the data store(s) and
the application itself. I'm not sure as yet how to accomplish this but it
may be possible.
On the application side of the providers, XML will be the returned value as
well as the (single?) parameter to each method. This will allow us to
develop for multiple physical tiers and provide web services (RSS based) for any
piece without a lot of additional coding.