|
|
| Line 1: |
Line 1: |
| [[Category:QuickOPC]] | | [[Category:QuickOPC]] |
| With the help of various conventions, we try to make it easier to find and discover the information needed, and understand the components’ internal consistency. | | With the help of various conventions, we try to make it easier to find and discover the information needed, and understand the products’ internal consistency. |
|
| |
|
| == Date and Time Conventions ==
| | There are also more specific conventions, used where appropriate: |
| * All OPC-related properties that are of {{Style=Identifier|DateTime}} type (and are consistently in UTC) have corresponding properties with a “{{Style=Identifier|Local}}” postfix, which contain the same value but expressed in local time. For example, {{Style=Identifier|DAVtq}}.{{Style=Identifier|Timestamp}} contains a timestamp in UTC, whereas its {{Style=Identifier|DAVtq}}.{{Style=Identifier|TimestampLocal}} contains the same in local time.
| | * [[Development Conventions]] |
| | |
| == Naming Conventions ==
| |
| | |
| === Common Naming Conventions ===
| |
| * In OPC-UA, the name part “{{Style=Identifier|MonitoredItem}}” is used wherever the type or member applies to both Data Access and Alarms and Conditions, whereas the names that use the term “{{Style=Identifier|DataChange}}” apply to Data Access only.
| |
| | |
| === Type Names ===
| |
| In addition to being compliant with common Microsoft recommendations for names, and in the .NET part with Microsoft .NET Framework guidelines for names, we follow certain additional naming conventions:
| |
| * Types which are specific to very simplified (“easy”) model for working with OPC start with the prefix {{Style=Identifier|Easy}}.
| |
| * Types which are specific to OPC Data Access start with {{Style=Identifier|DA}} (or {{Style=Identifier|EasyDA}}) prefix, types which are specific to OPC Alarms and Events start with {{Style=Identifier|AE}} (or {{Style=Identifier|EasyAE}}) prefix. Types that are shared among multiple OPC specifications do not have these prefixes.
| |
| * Types which are specific to OPC Unified Architecture start with {{Style=Identifier|UA}} (or {{Style=Identifier|EasyUA}}) prefix. Types that are shared among multiple OPC specifications do not have these prefixes.
| |
| | |
| Note that the second and third conventions work in addition and together with the fact that there are separate {{Style=Identifier|DataAccess}}, {{Style=Identifier|AlarmsAndEvents}}, and {{Style=Identifier|UA}} namespaces for this purpose too.
| |
| | |
| The above described conventions also give you a bit of hint where to look for a specific type, if you know its name. For example, if the name starts with DA or EasyDA, the type is most likely in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}}.{{Style=Identifier|DataAccess}} namespace. Without any special prefix, the type is likely to be in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}} or {{Style=Identifier|OpcLabs}}.{{Style=Identifier|BaseLib}} namespace.
| |
| | |
| === Interface Names in COM ===
| |
| As opposed to .NET, every object access in COM is solely made over its interfaces. In COM, after the object is instantiated, you never “see” the object as such – only the interfaces it has. Therefore, at least one additional interface (besides the COM-defined IUnknown and IDispatch) is needed on each .NET exposed to COM.
| |
| | |
| We consistently use following conventions in COM:
| |
| * Incoming interfaces have a form of {{Style=Identifier|_''XXXX''}}, where ''XXXX'' is the distinguishing part, e.g. {{Style=Identifier|_EasyUAClient}}, for the {{Style=Identifier|EasyUAClient}} object. | |
| * Outgoing interface (for events) have a form of {{Style=Identifier|D''XXXX''Events}}, where ''XXXX'' is the distinguishing part, e.g. {{Style=Identifier|DEasyUAClientEvents}}, for the {{Style=Identifier|EasyUAClient}} object.
| |
| | |
| The incoming interface are dual interfaces. The outgoing interfaces are dispatch-only interfaces, hence the use of ‘{{Style=Identifier|D}}’ as a prefix.
| |
| | |
| === ProgIDs (COM) ===
| |
| In COM, all our objects have ProgIDs that are identical to their qualified type names in .NET. For example, the main {{Style=Identifier|EasyUAClient}} component resides in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}}.{{Style=Identifier|UA}} namespace, and its fully qualified name and therefore also its ProgID is “OpcLabs.EasyOpc.UA.EasyOpcUA”. The main {{Style=Identifier|EasyDAClient}} component resides in the {{Style=Identifier|OpcLabs}}.{{Style=Identifier|EasyOpc}}.{{Style=Identifier|DataAccess}} namespace, and its fully qualified name and therefore also its ProgID is “OpcLabs.EasyOpc.DataAccess.EasyOpcDA”. This convention makes it easy to instantiate COM objects, based on the namespace-qualified names of their .NET counterparts.
| |
|
| |
|
| == Coloring Conventions == | | == Coloring Conventions == |
