For each table and table view, DataObjects for .NET generates a class (data object class) representing its row. For example, ProductsRow is an object (business object, data object) where each field has a corresponding property (ProductsRow.UnitPrice, ProductsRow.UnitsInStock, and so on) and each relation has a corresponding method (Products.GetOrder_DetailsRows, and so on) allowing you to obtain child rows and the parent row). Using these classes, you can write your business logic code in a convenient, type-safe way, and benefit from Visual Studio code completion features giving you the lists of properties and methods to choose from.

To use a data object class in your code, call the static Obj method implemented in every data object class. It obtains a business object given a C1DataRow object as its argument. For example, the following code obtains a ProductsRow business object from a C1DataRow:

To write code in Visual Basic

Dim dataRow As C1.Data.C1DataRow
Dim product As DataLibrary.DataObjects.DataSet.ProductsRow
product = DataLibrary.DataObjects.DataSet.ProductsRow.Obj(dataRow)

To write code in C#

C1.Data.C1DataRow dataRow;
DataLibrary.DataObjects.DataSet.ProductsRow product;
product = DataLibrary.DataObjects.DataSet.ProductsRow.Obj(dataRow)

Data object classes are hosted in the data library. They are automatically regenerated by DataObjects for .NET at design time every time you save a schema in the Schema Designer. They are hosted in a special assembly (called data objects assembly)

Data object classes belong to the namespace

where <data_library_namespace> is the namespace containing the C1SchemaDef component in the data library.

Since there is a data object class for each table and for each table view, a naming collision can occur for data object classes if a table view has the same name as the table on which it is based. Although all naming collisions are automatically resolved by adding "_table" and "_tableView" suffixes to the names, it is better to avoid such collisions because they result in ungainly class names. To avoid naming collisions between table and table view classes, use the DataObjectsAssemblyFlags property. Setting DataObjectsAssemblyFlags.DataSetNamespaces flag in that property (it is set by default for new projects) creates a separate namespace for each data set, and table view classes belong to that namespace. For example, Northwind.DataObjects.CustOrders.EmployeesRow for table view Employees in data set CustOrders. Table classes still belong to the root namespace: Northwind.DataObjects.EmployeesRow for table Employees.

A data library project contains a reference to its data objects assembly. When you create a new data library project using the C1DataObjects Project Wizard, the wizard adds a reference in the data object assembly to your data library project References. The data library assembly created by the wizard (initially empty) resides in the obj sub-directory of your project directory.

By default, Schema Designer regenerates the data objects assembly every time you save a schema. If you do not want this to happen (for example, if you do not need the data object assembly in your application), uncheck the "Recreate DataObjects DLL on saving schema in Schema Designer" check box in the Schema|Options dialog box of the Schema Designer. If you leave it checked, you can optionally specify the location of the data objects assembly and version information in that assembly. Note that if you change the data objects assembly location, you have to change the reference to that assembly in your project accordingly.

Data object classes can only be used with data libraries; they cannot be used in "direct client applications" that do not use data libraries; for more information, see Application Configurations.

A data object class is generated for each table in the schema (both for simple and composite tables) and for each table view in every data set in the schema.

A data object class (for example, OrdersRow) contains the following members:

• <field_name> – a property for each table/table view field. Example: OrdersRow.ShipAddress.
• Is_<field_name>Null() – a Boolean method without parameters returning True if the value of the field is Null.
• Set_<field_name>Null() – a method without parameters setting the field value to Null.
• Get_<parent_name>Row – a method without parameters returning the single parent row (or null) with regard to a relation in which this table/table view is the child. For inverse (many-to-one) relations, it returns the single child row.
• Get_<parent_name>Rows – a method without parameters returning the array of child rows with regard to a relation in which this table/table view is the parent. For inverse (many-to-one) relations, it returns the array of parent rows.

Using the DataObjectsAssemblyFlags property, setting the DataObjectsAssemblyFlags.StaticNameFields flag (it is set by default for new projects), adds more members to the data object classes. Those are static members returning constant names: field, table, table view and relation names, so that they can be used instead of constant strings in code thus making it compile-time safe (errors detected at compile time), for example:

• Northwind.DataObjects.EmployeesRow.FieldNameEmployeeID (field name returning "EmployeeID" for field EmployeeID of table Employees)
• Northwind.DataObjects.EmployeesRow.TableName (table name returning "Employees", for table Employees)
• Northwind.DataObjects.EmployeesRow.RelationNameEmployees__Orders (relation name returning "Employees - Orders", for simple relation "Employees - Orders")
• Northwind.DataObjects.CustOrders.EmployeesRow.TableViewName (table view name returning "Employees", for table view Employees in data set CustOrders)
• Northwind.DataObjects.CustOrders.EmployeesRow.FieldNameEmployeeID (field name returning "EmployeeID" for field EmployeeID of table Employees)
• Northwind.DataObjects.CustOrders.CustOrdersRow.RelationNameCO__ODP (relation name returning "CO - ODP", for view relation "CO - ODP" between table views CustOrders and OrderDetailsProducts in data set CustOrders)