Nebula MV ASP.NET Starter Kit?
We’ve been putting together an ASP.NET starter kit which may or may not be productized. It’s a Visual Studio solution / template which includes the following features.
- Master pages
- Themes / skins / styles
- Theme, database connectivity, and many other parameters defined in web.config. This allows for global site changes without code changes.
- Ajax-enabled forms, some making use of the Ajax Control Toolkit.
- Standard Login controls which use a custom MembershipProvider and RoleProvider which I wrote to use an MV DBMS as the data source rather than SQL Server.
- MV Data Access Layer (DAL) which allows a Business Logic Layer (BLL) to transparently use MV as a data source. You should be able to use this with an IronSpeed front-end, SubSonic (FLOSS), or other tools that generate the front-end and business tier of an MVC architecture.
- There are examples of BLL classes which serve as ObjectDataSources to bind directly to webform controls like Combo/DropDown lists and the GridView. In English this means you can exchange data with complex controls with a combination of BLL rules and BASIC from the server.
We’re trying to create good examples of many types of interaction with the browser, with data validated on the client when possible, on the web server when preferred, and on the DBMS when preferred/required. According to the plan, except for the DAL and custom membership classes all of the source code will be provided in the package.
Updates will include:
- Links to helpful websites, forums, and web pages – the better resources for learning and getting help.
- Explanations, tips, and tutorials for some of the techniques included in the kit.
- More code for specific functions like web services, data exchanges between relational and MV platforms, XML reading/writing and serialization.
- More sample pages that include features commonly used in development.
The idea is to help kick-start the learning curve for MV developers who are new to ASP.NET, and make it a little easier for them to take the plunge. This also may encourage more people to use tools like mv.NET, or to get development services from Nebula R&D, knowing that they will be able to maintain some or all of the code after we’re done with the initial development. In fact, the kit is being developed using code from actual projects that we’re working on now and putting into production sites. (No, there’s nothing proprietary in there.)
I really don’t know if this is going to fly and I sort of doubt it will, but as we go the kit is being built and serves as a base package for us to start working on new sites. So it’s real code, always evolving, and I think it would be helpful to others.
What do you think?
4 thoughts on “Nebula MV ASP.NET Starter Kit?”
Leave a Reply
You must be logged in to post a comment.
Great Idea will be much appreciated
I like the idea too. If you need any collaboration writing / testing let me know. I’m working with mv.NET.
Have you made any headway on the starter kit yet? As discussed previously I could provide some help.
We’re using it for a few clients now and constantly adding to it. Considering the time that’s been invested so far it looks like this will be a commercial offering at some point. For our clients who may be looking at 50-100 hours of development time just to get to this baseline, we could offer it at a substatial discount from the actual development cost as part of a longer-term agreement. I really don’t know yet.
There are two issues with this so far.
The first is that the baseline easily gets out of sync as soon as we update a client application with customizations. It becomes very difficult to roll enhancements back into the base and to roll enhancements from the base back out to our clients. I don’t have a solution for this yet outside of being meticulous about using a number Design Patterns to help prevent too many dependencies among components. I also don’t have time to sync code among clients and baseline, so the more we code the more out of sync it gets. I need to allocate time just to sync the packages, which is counterintuitive with the idea that this is supposed to save time.
The second issue is that we just became resellers for Telerik RAD Controls (announcements to be made soon but you read it here first!) and while I’d like to incorporate these controls into the package there will be some sites that don’t want to use them. So this means we’ll need two different packages. There are a lot of algorithms that don’t involve the UI, like the MV Membership Provider, but the Master Pages, Themes, and anything else related to Ajax all work differently. In short, you can easily "ajaxify" non-ajax code with the controls, but you can’t "unajaxify" RAD Controls for an environment that doesn’t want them.
That’s where we stand now. Thanks for asking about this guys. I’ll update here if anything changes.