I started to read the "Framework design guidelines" book; it's definitely one of the most interesting books I have ever read. I'll write in my next posts some interesting ideas from this book.
When you start to design your framework you should give simple and powerful tools. Try to match your framework to users with variety skills and abilities that write in different programming language.
Progressive Framework - create a common framework for all situations. Unlike VB and MFS, when you need to develop a complex functionality in your page, it does require a lot of efforts from you and high understanding in MFS.
Fundamental principles of framework design:
# Scenario driven design – first write the scenario and code samples (even in different language) that uses the API's, and only in the end implement it.
# Low barrier to entry – Your API's must be easy to use even by inexperience programmers. It will be easy to find the members and types for basic operations (i.e. divide them to good namespaces: main namespace will contain the common parts like System.Net for example, and sub-namespace will include the extended parts like System.Net.Sockets).
# Trivial usages – just write the commands without initialize some parameters, provide good constructors and override methods (with short and primitive parameters list and intuitive default for them).
Good error message helps to find the wrong use.
# Self documenting object modules – in the simple cases users use the API without any documentation. Although you should write a full documentation for the API for complex case and to give a choice to pre-implementations learning.
Naming: The name is the major factor on the quality of the self-documentation.
Save good names for the classes that really need it. Don't afraid to give a verbose identifier names.
# Exceptions – write explicitly the wrong use in error messages.
# Strong typing – One of the most important subjects is giving intuitive API.
Use User.Name(return string) instead of User.Properties["Name"](return object).
Try to wrap the common properties with a strong type.
# Consistency – Try to be consistent with old API's, it will help with the self-documentation.
# Limiting Abstractions –avoid the use of many abstracts because only an experience architect can implement it (even in the simple cases).
# Layered architecture – divide clearly to a low-level API and a high-level API for high productivity in work. Don't mixes levels in the same namespace try to divide to sub-namespace.(i.e. System.Web contain a low level Http Runtime API's on the other hand, System.Web.UI contains high level page and controls API's).