View
MoOv
D
o
a
m
t
d
v
C
e
v
s
T
c


Log Messages and Errors

Mouse Events

State
State
Test Console

Test Data

Application Framework

OSS Operating System Support

MVVM
Model-View View-Model Framework

This framework version includes trace, status line, logging, threaded messaging (both user interface and functions,) console, disk and database file I/O, error handling, start/pause/cancel, progress bar and other features.

Discussion of framework patterns,
issues and risks.

I have frequently read statements that imply that all frameworks have an inherent flaw via duplication of operating system (and other) functionality. In the end an anti-design pattern.

I would generally accept the view that needless duplication should be avoided. But of course the issue is more complex and takes place in a context that includes the user experience, diagnostics, exception handling, component use and more. I would at least argue the above should equally include the full scope of the .Net framework as well.
Overriding all of this though is the very nature of components that mediate between the end user and the underlying technologies like .Net or MySQL. An OSS layer in many respects reflects the underlying OS and DB and communications. It must.

I don't think anyone would reasonably disagree that it is important to fully exploit performance and always avoid duplication where the OS, .Net, and Interop are concerned. Even on that basis the above OS functionality is just one amoung many equally important issues, for example, user experience.

Enterprise applications can be used by smaller compainies as well as large. For much the same reasons, smaller enterprises are looking for robust feature rich applications that are consistent and reliable. I see an OSS as a tool to help achieve that requirement.

Complex applications will invariably have a framework layer of some sort. It's not that it is impossible to use other implementation designs each with it's own limitations. But they are all required to addrees user interface and experience and handle exceptions at a minimum. They are certainly increasingly likely to be found as the app's sophistication grows and with the later integration of other robust or complex applications.

But it seams reasonable that you would take care the OS portion of that code that could lead to duplication as a matter of course. Similar to tuning the DB and optimizing the project critical routines.

In a similar way, fully expolioting .Net's functionality is important and duplicating its functionality generaly wasteful. But this is true of many related details, such as the above developing a consistent and helpful user interface for handling exceptions.

To some degree, the framework acts as a mediation layer handling the, OS, state, database, etc. while it contributes to a consistent and quality user interface.

In the end, the line that separates duplication and excessive standardization from a robust implementation of under-lying IDE framework classes seems highly subjective. I think I would far more encourage concern and scrutiny for the framework's impact on performance and resources rather than abandon what is to me, a proven best strategy.

The original OSS application additionally includes secure user sign-on, company control, smart file locking and metrics, hardware usage configuration, scheduled tasks with input, minor accounting controls, resource management and other features.

That being too broad an initial scope combined with the need to complete detailed evaluation during the first Phase prioir to the finalized design. The above features were placed in a later phase.

Rationelle:


All enterprise level applications share similar issues in the need to provide a consistent, informative approach to such issues as User Interafce, Error Handling and Security. Achieving this requires an OO interface layer of some sort to present an informative and pleasing user interface. I refered to this as the Operating System Support layer or OSS of an application.

The database (file system components) need to be included or integrated with the OSS so that messages can be processed and presented to the user. By adding the file system component, the OSS can also explore other levels of the database hierarchy to determine the cause of failure.

The scope of an OSS is potentially quite wide including user experience, diagnostics, exception handling, resourse allocation, load distributioin, security, menus, bars and shortcuts, automated testing, demos and kiosks, work-flow, collaboration and more. As the number of users grows it becomes increasingly advantageous to have it or an equavalent.

To Create a robust applications environment powerful enough to support scheduling, logging and state analysis.

There is first the expectation that a consistent UI will be developed regardless.

Second, an application specific design is expected to handle issues like exceptions and cross thread communications gracefully.

Finally, there are many feautures so pervasive or cross-cutting that an OO component solution is reasonable.

Advanced conversion features launched by an easy to use interface.

The main page includes a progress bar and adjustable levels of progress details. It is a diagnostic utility and featurse a real-time raw data windows, pause to examine and detailed exceptions handling.


The database information page allows entry of the standard database attributes including server, database, filegroup, user, password, authorization.

Implementation of file owner as well as populated drop downs for each database attribute are still pending.


File Subsystem

Handles SQL, Ascii, Binary and post-relational database files. Equipped with an auxillary connection. Comprehensive data format and schema transformation.

The Project

The requirements for this project were that is first and foremost produce the necessary framework classes that would be used by any typical business application under .Net.

Second, was the need to implement a minimum set of features from the existing Axion / MDM OSS module in a manner appropriate for .Net. This would include a small number of enhancements and changes to the components involved in the project.

Third, was a desire to implement a small set of usefull language and string extensions and features not already existing in .Net.

Fourth involves a trip down the rabbit hole and a number of issues. To deeply explore the effects and costs of deferring the creation of clean classes to save time early in the project. The efficiency of transcription of classes and code from other environments. The manual process of code conversion to C# with a view to automated processes. In general, an further evaluation of the requirements to create OO classes from platforms other than .Net. Later a review of the DLR was added.

Six, a more pragmatic approach code conversion where some determination would be made regarding implementing the existing applicaitons under C#. This included the user interface, specifically maintenance and data entry forms as well as existing generated forms. It also included file, database, transaction and distributed processing issues. This would conclude with a followup review of web enabling existing applications by generating HTML rather than text versus generating Silverlight under C# (using the framework.)

Finally, I was interested in exploring features of C# that I was not properly familiar with in a hands on fashion. In particular this included weak object types and introspection but also included features such as LINQ, generics, WPF / Silverlight, etc.