>What you are doing sounds really great, you are very practical in your approach which is also what we are trying to do. However we do still most of our work using our VFP framework, which has similar characteristics as your .NET framework, with the difference that we can create only desktop applications. We feel that the market demands more web applications, and therefore we also started on a MVVM framework in .NET and C#, but we are back and forward with thinking to use Silverlight as frontend, because of all the different opinions we are careful not to go onto the wrong train. Also our VFP framework is so mature that it is difficult for us to imagine to have a similar set of tools anytime soon in .NET, you are looking at a long timeframe.
>You say you do mentoring, does that mean you are promoting your framework as commercial framework? I would be interested how your applications look like, and how you deal with the usual problems when moving a desktop application to the web, like asyncronous processing, reporting and deployment.
Yes, exactly, this is what I did when I was in VFP. I had one for each environment. This is one thing I learned when I switched to .NET. It was more complicated, required a more precised architecture, but one framework fits it all.
The timeframe conversion you mentioned is, as you said, one good thing to analyze. It took me two years to convert it and three more to upscale it to a level which is now about 20 times better than the previous one. So, that costs a lot and in time as well. It requires a lot of testing, and sometimes, resources to handle it all.
And, so sadely as it is, nothing is permanent. So, there will one time when this process will have to be done again into another environment. I just try to keep hopes that .NET will be there for longer or as long as VFP was.
The framework is not vertical market but it might be. One of the things I am incorporating in it during these days is the spatial data type support, which you probably have seen in some related threads, and obtain proximity search. So, basically, from the dictionary, by doing the proper definition on a field, the application can benefit of proximity search, Google map and so on without one single change in the code.
Moving the desktop applications to the Web is something that I haven't seen since a while. As, since several years now, all I have seen is requests to have Web applications. That also includes full accounting system and so on. Everyone wants to be able to access their application through the Web so the need for desktop applications is dropping. For reporting, it is HTML all the way with table or simple reporting with the list class, such as on this site in many places where you can filter, navigate and so on. And, the list class also supports Export to Excel either from visual data representation in the list or raw format by including all the fields from the table in regards to a record in a list. This is like having a list with 7 fields but the table contains 32 fields. So, when choosing or offering the other format, this allows the user, or should I say super user, to see the entire record in Excel. As for deployment, piece of cake. Or, walk in the park as this is the easiest part of all. You just upload the updated DLL and IIS and the .NET framework recompiles it into memory on the first hit. So, there is no stopping IIS and related issues. Issues in regards to that, when moving from development, to test to production, also includes the data dictionary maintenance where a field can be defined in the data dictionary but not Enabled yet. Thus, when going into production, after the upload of the new DLL is done, the related fields can now be enabled.
