DataObjects for .NET allows developers to specify business logic in code on table level. This is the main power feature of the DataObjects for .NET framework: specifying business logic where it belongs, on a data object (table) level and its automatic propagation and enforcement wherever that object is used.

DataObjects for .NET executes table-level business logic code wherever the table is involved: in a composite table including this table and in a table view based on this table.

You can also specify business logic on data set level. Such code will be executed only in a particular data set. Using dataset-level business logic allows the user to enforce rules that are specific to a certain data set. For more information, see Data Sets.

Developers write table-level business logic code in the events of a special C1TableLogic component. Only one C1TableLogic component is allowed for each table. To create C1TableLogic components, right-click the C1SchemaDef component and select CreateBusiness Logic Components from its context menu. The C1TableLogic components are automatically added to your form. You can also add them manually from the Toolbox by double-clicking the C1TableLogic component and setting their SchemaComponent and Table properties.

Once you have added the C1TableLogic components, you can attach event code by either selecting the components on the designer surface, or by using the Business Logic Events tool window. Right-click the C1SchemaDef component and select Business Logic Events from the context menu to open the tool window:

The Business Logic Events tool window shows the list of all tables and data sets. When you select a table in the tool window, the table's business logic events appear in the Properties window (in Visual C#, when the Events radio button is selected in the Properties window; in Visual Basic use the Method Name combo box in the code editor).

DataObjects for .NET also allows you to associate business logic code with table views instead of tables. This is done to specify data set-specific (table view-specific) logic, rules that must be enforced in the context of a particular data set and table view, but do not always apply to the underlying table. In this case, a C1DataSetLogic component is used, for more information see Table View Business Logic Events.

The following is a brief list of business logic events available in DataObjects for .NET (note that the Before and After prefixes pertaining to most events have been omitted and the prefix is only included if an event occurs only Before or only After):

Event	Description
AddNew	Fired when a new (empty) row is added.
AfterChanges	Fired when all changes initiated by a field change are done and handled by the business logic code, see the FieldChange event.
BeginEdit	Fired when the user starts editing a row (data-bound controls start editing a row immediately after they position on it, even though no changes have been made yet).
CancelEdit	Fired when the user cancels editing a row reverting the changes made to it.
Delete	Fired when a row is deleted.
EndAddNew	Fired when a newly added row becomes a regular row in the rowset. When a row is added, it is added empty, its primary key is unknown. A row with unknown primary key is in special transitory state, it is not a regular rowset row. Only after its primary key is set it becomes a regular (added) row, which is signaled by this event.
EndEdit	Fired when the user finishes editing a row (data-bound controls finish editing a row when they leave that row, even if no changes have been made).
FieldChange	Fired when a field value is set. Inside this event, your code can set other fields triggering recursive FieldChange events, DataObjects for .NET handles this situation correctly. Only after all changes are done and handled, the AfterChanges event is triggered.
FirstChange	Fired when a first change is made to the row (a field value changed) after BeginEdit.
UpdateRow	This event is not fired in a client application, unless it is a direct client, that is a 2-tier application updating the database directly from the client, see Application Configurations. In a 3-tier deployment, it is fired only on the server, when a modified row is committed to the database. See also, Updating the Database.