VITA - What is Different?

Component packaging technology.

For the first time, it provides a usable, working technology of breaking a database application into modules which can be independently developed, tested, distributed and reused. Read more about component packaging here.

Built with Real-World Applications in Mind.

The architecture is built with consideration of real-world applications requirements. Most ORM's ignore the fact that CRUD operations are not the only low-level data operations that must be supported in database applicatons. There are many other things that Entities must be able to do. One example is authorization - in a typical business application, there are strict rules about who can see or update what - what entities, what fields. These authorization rules are configured at the finest level of granularity in database (not statically set at application design!). Any data access (read/write of individual fields) must go through authorization check that verifies that this user can indeed read or update this particular value. Therefore the entities provisioned by an ORM must provide an easy hook for such an authorization subsystem.
That's not the case with existing ORM's. The ORM creators simply assume that everything ends with delivery of values from database table into some object in memory. The result is a defeat of the entire concept: the benefit of having ORM is practically lost. If I get my data access clasess and entities generated in 1 minute, and then spend 3 months plugging authorization code into them - is it really that much better than going without ORM and writing from scratch all entities with data access and authorization checks in the same 3 months? The timeframes might differ, but in any case, it is no longer minutes vs months.
In contrast, VITA was designed with this consideration in mind. In VITA's entities, there are two core methods that ultimately handle field-level access: GetValue and SetValue in DataRecord class. These are the points where we need to hook authorization subsystem. Similarly, these methods will fire all "change" events, handle lazy loading, etc. No endless lists of "observable properties" with the same NotifyChanged call like we see in "POCO" entities in other ORMs.
There are many other aspects that work well with VITA's architecture. As an example, VITA's entities are self-tracking - entities keep original and changed values behind the scene. The implementation is very efficient and automatic for the developer. Some ORMs can do change tracking for you, but do it quite inefficiently, and usually implementation comes with extra limitations and imposed requirements on your entities.
To sum it up: VITA's architecture is designed with real world applications in mind, with hooks to extend and implement the features that a MUST for most data-connected applications.

The Small Size.

It is in fact a very important factor. VITA codebase is small, almost tiny, not a monster like many other frameworks. A single assembly, less than 250Kbytes in 70 source files. This is important for an open source project - the whole point of open source is that you have the ability to look inside to see how things work and even fix it if something is broken. What is important, is that the open code base is of reasonable size and complexity - otherwise, "it's not an open source, it's an open mess" - as one author had put it. Source code is not much help if there's way too much of it.

Last edited Apr 6, 2011 at 10:58 PM by rivantsov, version 8

Comments

No comments yet.