Ever since my little adventure in C# and Collection services, I’ve been thinking more and more radical ideas about CRUD operations in an application.
Hibernate is a nice tool for solving the persistence part of an object space (i.e. the objects that make up a system); this and similar toolkits provide the functionality to stream objects from persistent storage (e.g. databases) into memory. But there are many other repeatable components in an application.
Why, for instance, do I always have to build a GUI? Why do I always have to build an application? Define windows and menus? Build message loops, include frameworks… painstakingly design every window and every form by hand?
There should be an easier way.
The theory of Naked Objects is a nice way to go forward, I think. An object should contain enough information about itself, such that an efficient GUI could extract the methods and properties of the object, display it, and handle all the CRUD operations itself. With enough attributes, run-time type information or reflection, it should be an easy trick to pull off.
A form designer might be introduced to order the information in a convenient manner, but would only have access to the actual component being edited.
What are the common properties of these operations? I must be able to
- Fetch a list of objects, or fetch a list of references to objects (ID values)
- Fetch an individual object
- Create, edit or update an individual object
- Delete objects
- Manage links between objects
It seems to me that the parameters of object-oriented development already allow for these things. It seems to me that it should simply be a matter of designing objects for published use (to follow the Delphi terminology).
With a few descriptive statements about the system, it should be theoretically possible to build an entire application out of objects alone, without GUI, without persistence code, without tedious manual labor of slaving for hours over application-specific code.
Most of the common design patterns could be used to abstract and simplify the behavior of a multitude of objects into a coherent workspace. The definition of an application could effectively be the workspace of related objects, components, abstractions, models and views that implement a specific domain of tasks.
By relegating the effort of creating a uniform GUI for a single application to an operating system-like helper component, it would be possible to transcend the plethora of application designs, skins and various other interface-related mechanisms and seemingly integrate all of the applications into one coordinated user experience, without necessarily experiencing the negative effects of today’s COM-based approach.
A setup like this could very well be agnostic to the specific user interface. Depending on the application helper component, it could be a GUI, a system presented through a text-only terminal, or a web-based solution (with or without AJAX).
Basically, I’m just thinking out loud, but it’s not a bad idea.