UDF Component Architecture

I've been focusing on describing specific attributes of the architecture of user defined fields (UDFs), but I haven't shown an overall diagram yet.

[caption id="attachment_50" align="alignnone" width="1212"] UDF Component Diagram[/caption]

The UDF component architecture is generic. This allows there to be multiple implementations of any given component. As long as there are a set of interfaces that any layer implements, this can support many different implementations for each layer and component.

UDF Storage is the place that the data is ultimately stored. It could be an RDBMS, a document (NoSQL) database, text files, or anything you want it to be.

UDF Security is a cross-cutting component or concern. For each layer in the architecture, security needs to be applied to maximize data protection. At the data store, user authentication and authorization may be employed. The model layer can apply the security to metadata, tables, or fields and it may be based on role or by the data itself. Data validation and information hiding/disabling can be applied at the controller and view layers.

The Storage-Specific Data Access component contains classes that implement interfaces in the model and know how to manipulate the data in UDF Storage. This abstracts the data storage from the model and allows this component to be interchanged outside of the model. (The code I'm building has this bundled in the model, but this is not necessary.)

The UDF Model component and sub-components contain the code to orchestrate and do error handling for UDF storage manipulation. It can also allow for forgiveness (undo) if desired.

The controller classes hook the view to the model, as in any MVC architecture. They can use the security and validation layers to check the data and user actions from the view. The security layer can be used to check for enabled, disabled, or hidden fields in the view. This allows for a better user experience (prevent actions that are disallowed vs. telling the user they are disallowed after they take an action).

To summarize, this is an MVC architecture that allows for the user to define dynamic fields and enter data into them. It manipulates the data storage, which can be used to optimize performance and efficiency to support whatever attributes are desired from the application. Because the view is abstracted, it can be created in any number of ways: a thick client, a thin/web client, a mobile client, etc. The interface between model and view could be a direct call or it could be a web service call. The number of variances is fairly wide. I will be concentrating on building a web client on top of web services using a PostgreSQL database. If I find the??time, I will implement security and validation.