| |
| | Advantages The Opf3 Framework saves you a lot of your time!  | Opf3 is build to take fully advantage of the new .NET 2.0 features. It supports generics, partial classes and nullable types everywhere. You can use generic lists or generic persistent objects; Opf3 will just work fine with them. |  | The framework supports also the new 64 bit architecture and leverages the full speed of it. You don't need to change anything! Just compile Opf3 with the .NET 2.0 Framework for 64 bit and everything will work fine. |  | Create multiple instances of the ObjectContext class and connect to multiple storages to work (at the same time) on different storages in your application. It seems as if you are working on one storage. You may even copy objects from one storage to another with little work. Read more... |  | Opf3 is fully compatible with .NET remoting and web services. The framework can remote objects (out of the box) from one computer to another without loosing any additional information. Even on multi-user system you can remote objects without loosing the multi-user benefits, such as concurrency control. Read more... |  | Databinding and Opf3? No problem! The framework supports the data driven controls coming with .NET 2.0 or of thirth party vendors. You may also use complex binding with Opf3's persistent objects and object lists. |  | Supports ASP.NET 2.0 by minimizing the ViewState overhead for persistent objects (a lot data is stored directly into the session and not in the ViewState). Read more... |
But that's not all! The framework offers a lot more. Some of the other benefits are: - Fully customizable: Create your own storage classes, concurrency algorithm, user defined types (UID), ObjectSearcher, query types, object lists and a lot more.
- Derive persistent objects from
System.Object or any other base class. - Storage independent queries: To get objects from the storage you can specify storage independent queries. To specify conditions and sort orders you use a storage independent query language called OPath. In that language you have to use the names of the properties of the persistent objects (instead of the names of the fields in the storage). This and other features of the language make it storage independent.
- Completely storage independent: Your application is storage independent. You may switch from one storage to another whenever you want.
- Everything can be an Identifier. Just mark it as Identifier using the FieldAttribute's property "Identifier".
- AutoIncrement values for Identifier (primary keys) by setting one property of the FieldAttribute.
- Create relations between your objects by setting one custom attribute. The framework supports one-to-one, one-to-many and many-to-many relations.
- Create the mapping between your object and the entity or fields in the storage by using simple attributes. No writing of queries to save, load, delete persistent is required.
- Concurrency checks on plugin basis. The framework ships with one convenient concurrency algorithm implemented (using Md5 checks).
- Store the result of your query in an
IList<T>. You may also use the implemented ObjectSet Class (represents an in-memory cache of objects). - Events for each operation on your persistent objects. Get an event before and after each insert, update, delete, load...
- Use the powerful ObjectSearcher to get objects from the storage. Or implement your own "Searcher" by deriving from ObjectSearcher and using it's powerful methods.
- Extend your persistent by using DynamicProperties. DynamicProperties allow to extend your persistent dynamically, even the customer may extend a persistent on runtime (if you allow it). DynamicProperties are converted to Xml and stored in the storage. See the DynamicPropertiesContainer class for further information.
- Implement the IUserDefinedType interface to store any type of object in a field in the storage. By implementing the interface you can store anything to a field in an entity of your storage.
| |