What is the best way to approach creating a corporate .Net Namespace framework from scratch?

Question

We are migrating our applications to VB.Net 2008 from Classic VB and I need to create a base namespace and business layer. My method of approach is going to be to visit our top BA and identify the common areas of our (Fixed Income) company and try to form a decent inheritence model with as much of the code in generics as possible.

What's everyone's experience of doing this and also as a second part of the question, we are looking at incorporating Web Focus into the OLAP side, how would this affect the design of the corporate namespace and it's derivatives?

Answer 1

I think the best way to begin to create a corporate .NET framework is to begin by harvesting existing code out of current corporate projects. Building a framework from scratch by talking to a BA without writing code for a specific, concrete project might lead you to over design the framework in some areas and totally miss some necessary features in others (as well, it might place artificial constraints on your framework clients for no good reason).

See Fowler's entry on Harvested Framework and this blog post for a more complete explanation.

I'm not familiar with Web Focus but I'm guessing it would affect it in some way, however, if you go with a Harvested Framework, your usage of it in the first few applications you build will shape how you use Web Focus within the framework.

Answer 2

Jereme has it right on the framework. I'll briefly mention something obvious about namespaces.

Always remember what a namespace is for - it's to provide a "space" in which names will live. In particular, it's meant to provide a space small enough that the people creating names within that space will be less likely to produce duplicate or confusing names.

This can only work if the namespaces are organized along patterns of organization, or of domain knowledge. A simple example often used is a pattern of Company.BusinessUnit.Application. The theory is that within the set of developers working on a given application, there is less chance for name duplication. This will not be true for a large application, where you would want to break it further based on layer or area. Similarly, of the business unit is too large, you'll want to break that down.

But in all cases, you're really trying to partition sets of brains, as it's the brains that create the names.

Answer 3

If your application is under VB6 (not VB3) then I strongly recommend that do the redesign to a class hierarchy in VB6 first. The reason for this is that in any conversion you try to preserve the behavior of the old application. Is stretches out the project time to do this and do a redesign at the same time.

By making the design changes in the applications original language first then you are assured that any bugs that result are due to the design not the conversion.

I done three major conversions of our software in the past 20 years; (DOS to VB3) (VB3 to object oriented design in VB6) and (VB6 to VB.NET).

Finally it is straight forward to make a design in VB6 that is ports over to VB.NET readily. The trick is to hide the specific VB6 APIs and constructs behind a interface (graphics, printing, etc)>

When do the conversion I recommend working from the top down. Change over your forms first to .NET which calls the VB6 COM DLLs. Then convert each layer over until you reach the bottom DLLs.

Again, if you try to change the design AND convert to another language for any complex application you will double the conversion time.