Its about 8 months since I posted. The question is still hot.
During this time we added public types to deal with custom tab stops (about 5) and lists (about 8) into the Aspose.Words namespace.
We've also developed a whole new set of classes to deal with drawing objects and created a new Aspose.Words.Drawing namespace for it (about 30 members now).
Because some public types actually migrated from Aspose.Words to Aspose.Words.Drawing, the total number of public types in the Aspose.Words.Namespace remained about the same. I can count 125 at the moment and I still think it is a bit too much.
Whenever a user wants to accomplish a certain task, he should basically see only the classes and enums he needs most. I think the Aspose.Words namespace should include only the most frequently used types. For example Document, DocumentBuilder, Paragraph, Run, Font, ParagraphFormat and so on - there is no question they all should sit in the single Aspose.Words namespace.
But a lot of public types in Aspose.Words must be used pretty seldom, for example LineNumberRestartMode, Comment, Footnote, ChapterPageSeparator, NotChangedEventArgs.
There are many other types which are hard to tell whether they are used often or not without hard usability data. They should probably stay where they are.
Apart from making no changes and keeping the Aspose.Words big 130 public members namespace, we are considering several options:
- Create namespaces by "functionality". Rough examples are: Aspose.Words.Fields, Aspose.Words.Tables, Aspose.Words.Lists and so on.
- Create namespaces by "frequency of use". For example Aspose.Words and Aspose.Words.Advanced (or Aspose.Words.Specialized).
Much of .NET Framework seems to be built with namespaces by "functionality" or "technology". But from what I gather, there is an interesting guideline that suggests designing namespaces in such a way they help users to be productive and separate frquently used classes for simple scenarios from advanced ones.
If we create Aspose.Words.Tables, Aspose.Words.Lists etc, then the namespaces will be pretty small (8-12 public types) and when you code, you will end up using most of the namespaces for many of your tasks. For example, if you are programmatically building a document, you would end up using table classes, list classes, document classes and so on and you will have to pull them all from different namespaces. I think it is yuck.
On the other hand, if we create Aspose.Words and Aspose.Words.Advanced, then 90% of the time you will just have to deal with classes from Aspose.Words (my estimate the number of public types will come down to 85). Only if you want to do some "advanced" thing, you will need to include classes from Aspose.Words.Advanced (or Aspose.Words.Specialized or whatever the name is). There are problems with this approach too. The main problem is that there is no hard and fast rule to decide which class should go into which namespace and the user will have no idea where to expect to find a particular type. Also, it will "conflict" with already existing "by-technology" namespaces Aspose.Words.Drawing and Aspose.Words.Reporting.
Basically, I don't want a single huge namespace because I don't think it is right for the users. But I also don't want too many small namespaces because you will end up using them all everytime. And the problem is I don't know how to divide the huge Aspose.Words namespace. What is the right size for a namespace? My gut geeling the maximum is around 50 public types.