[ROOT] / doc / toc / ARCCore / Class / IP / __TOCDet

KeyValue
AssemblyARCCore
DocFragTypeClass
NameIP
NamespaceARCCore
TypeIP

ClassAttribute

KeyValue
AssemblyNameARCCore
ClassNamespaceARCCore
ClassTypeIP
Interfaces-IEnumerable<IKIP>-; -IEnumerable-
InterfacesDirectlyImplemented-IEnumerable<IKIP>-; -IEnumerable-
SubTypesDimAccount; DimAccountCollection; DimCurrency; DimCustomer; DimCustomerCollection; DimDepartment; DimDepartmentCollection; DimEmployee; DimEmployeeCollection; DimGeography; DimOrganization; DimOrganizationCollection; DimProduct; DimProductCategory; DimProductCollection; DimProductSubcategory; DimProductSubcategoryCollection; DimPromotion; DimReseller; DimResellerCollection; DimSalesReason; DimSalesTerritory; FactCallCenter; FactCurrencyRate; FactCurrencyRateCollection; FactFinance; FactFinanceCollection; FactInternetSale; FactInternetSaleCollection; FactInternetSaleReason; FactInternetSaleReasonCollection; FactProductDescription; FactProductDescriptionCollection; FactProductInventory; FactProductInventoryCollection; FactResellerSale; FactResellerSaleCollection; FactSalesQuota; FactSalesQuotaCollection; FactSurveyResponse; FactSurveyResponseCollection; Root

IP = IProperty.

Common central mechanism for implementing PropertyAccess.

'Everything' in your application, especially entity classes (like 'Customer', 'Order' and so on) but also classes which are (in a hierarchical sense) over and under the entity level,
should implement this interface.

Examples of classes implementing this interface as seen from a hierarchical storage viewpoint:
PCollection: Collection of objects, like CustomerCollection.
PRich: Customer object.
PValue<T>: Customer.FirstName.
(note that the topmost level containing all collections should also implement this interface, this can be accomplished with the universal PRich class.)
You should also let internal parts of your application implement this interface. This will make logging and debugging much easier for instance (see ExposingApplicationState).

Methods that must be implemented are:
TrySetP
TryGetP
TryGetV
-GetEnumerator-
and also:
DeepCopy
TryRemoveP
OnTrySetP
TrySetPP
GetKeysEqualToValue

Some of the implementing classes in ARCCore are:
PRich Fully flexible storage. Can store anything. Typical inherited for entity representations like 'Customer' or 'Order'.
PExact<TEnumType> Very MemoryConsumption efficient alternative to PRich.
PConcurrent A (somewhat) thread-safe alternative to PRich which also supports ExposingApplicationState.
PValue<T> Single value storage.
PValueEmpty.
PCollection A class useful for storing a collection of entities (a table in RDBMS-terms) because it implements Indexing.
PReadOnly Experimental as of Feb 2022.

Use these as base classes for your own entities and properties in your ApplicationSpecificCode.

In ARCCore there is also -PCollectionES- which supports EventSourcing.

NOTE: Some ideas for new classes implementing this interface could be:
1) PRichImmutable, a quasi-immutable class for which you could (after initialization) set a flag stopping further updates to the class.

(The difference between ITypeDescriber and IP is that the former must be stored 'inside' an IP.
In RDBMS-terms a ITypeDescriber is the Field stored within a IP which is the Post.)

The more classes you have implementing this interface, the more classes you have that can participiate in the AgoRapide world with flexible concepts like PropertyStream, TaggingOfPropertyKeys, PropertyAccess, ExposingApplicationState.
The mechanism has been designed to be as flexible as possible. Experience shows that a great variety of objects can with great advantage be represented through this mechanism. That is, not only traditional entities like 'Customer', 'Order' and so on can be represented but also objects like internal parts of your application (classes, enums),
the different methods in an API and even reports and aggregations.

(Even the mechanism for describing this mechanism (PK) is an implementation of it).

HINT: Whenever you are creating a new class in your application, instead of using traditional setters and getters / traditional properties, let class inherit IP and use this mechanism instead.

Using IP from the start makes the rich functionality of AgoRapide available without much work. (You can always build traditional setters and getters and / or traditional property storage on top of that mechanism at a later stage if you so prefer)

Reflecting the fact that instances of this interface often contain a collection of objects, this interface implements the following:
1) Indexing. Enables you to query more 'direct' in C# like for instance 'DataStorage["Customer"]["42"]["FirstName"]'.
2) IEnumerable<IKIP>.
3) The Keys and Values pattern from ordinary .NET Dictionary (see Keys and Values.
This functionality is of course not relevant for value only implementations like PValue<T> but technically implemented nonetheless in all cases in order for any hierarchical structure to be 'probed' from the outside in a standardized manner.

TODO: Implement IDictionary<TKey, TValue> also..

See also PropertyAccess.

TODO: Regarding default interface methods defined here in this interface
TODO: and the need for implementing an 'IP' property in implementing classes like IP.
TODO: As AgoRapide matures, considering implementing copies of the default interface methods in a common super class
TODO: for PRich, PConcurrent, PExact (not necessary for PValue, PEmpty and not possible for BaseAttribute).

Note how AgoRapide internally uses this same mechanism ('eating its own dog food'), and also how you are encouraged to document your application through attributes like ClassAttribute and ClassMemberAttribute using the same mechanism.

Note about packing of values: PropertyAccess uses packed values (everything is sent and received as IP) meaning for instance that a string-value would typically be packed inside a PValue<T> object.
Connected with this, classes implementing IP have a choice between
1) Unpacking on receive, packing on send (like used by PExact<TEnumType>) or
2) Storing in packed form (like used by PRich).
The former is more memory efficient (see MemoryConsumption), but less able to store metadata (see PP) and hierarchical data.
(see also PackObjectForStorageInEntityObject and TryGetV.)
See also ITypeDescriber which provides a standardized mechanism for describing single-property values.

Edit


Generated 2024-03-28 09:51:01.609 UTC