Features List of SnapObjects 1.0.x

This document introduces the new features in SnapObjects 1.0.x.

SnapObjects Runtime Packages in NuGet

The following SnapObjects runtime packages are available for download from NuGet:

Supported Framework/Standard

  • Creating projects that runs on .NET Core/.NET Standard
  • Using SnapObjects.Data.AspNetCore objects for .NET Core
  • Using the following components for .NET Core or .NET Framework: SnapObject.Data, SnapObjects.Data.Oracle, SnapObjects.Data.PostgreSql, SnapObjects.Data.SqlServer, SnapObjects.Data.Odbc

Database Connections

  • Microsoft SQL Server

    Supported versions: 2016 or 2017

  • Oracle

    Supported versions: 12c or 18c

  • PostgreSQL

    Supported versions: 11.3, 10.1, or 9.6

  • ODBC connection to SQL Anywhere (64-bit only)

    Supported versions: 16 (16.0.0.2043 or later) or 17

Objects and their APIs

These are the key objects provided in SnapObjects:

  • DataContext

    DataContext is the object to manage database connections and transactions.

  • SqlModelMapper

    SqlModelMapper is a transaction-oriented data manipulation component compliant with .NET Standard. It can build models with data from multiple tables, support nested levels of relationships, and provide explicit and implicit transaction management for business entities (i.e. a top-level object and all of its children).

  • SqlExecutor

    SqlExecutor is a set of database manipulation interfaces that have encapsulated the core components of ADO.NET. Using SqlExecutor you can directly run dynamic SQL statements, perform SQLBuilder object functions, and do model queries.

    SqlExecutor supports raw SQL as well as automatic SQL generation, supports lazy loading of data to prevent unnecessary performance bottlenecks, and can bind result-sets to POCO or dynamic models.

  • SqlBuilder

    SqlBuilder constructs SQL statements in a progammatic and DB-agnostic way. With SqlBuilder you only need to build the syntax structure, and database-specific SQL statements will be generated based on the syntax structure and DataContext.

For more information about the objects and APIs provided in SnapObjects, see SnapObjects .NET API Reference.

Model Attributes

SQL generation is controlled through a comprehensive set of model attributes:

  • For defining SQL query: FromTableAttribute; SqlJoinAttribute; SqlColumnAttribute; SqlUnionAttribute; SqlWhereAttribute; SqlParameteAttribute; SqlGroupAttribute; SqlHavingAttribute; TopAttribute
  • For Defining SQL CUD: SqlcolumnAttribute; IdentityAttribute; PropertySaveAttribute; UpdateWhereStrategyAttribute
  • For Defining master-detail relationship: ModelEmbeddedAttribute; SetValueAttribute; SqlEmbeddedAttribute

Transaction Management

Transactions in SnapObjects can be either explicit or implicit:

  • An explicit transaction is one that you explicitly create by using context.BeginTransaction()
  • An implicit transaction inherently includes all the CUD operations on the model until a commit method (SaveChanges in SqlModelMapper, or Execute/ExecuteProcedure in SqlExecutor) is executed.

Different from SQLExecutor, transactions in SqlModelMapper (no matter explicit or implicit) can include not only CRUD operations, but also SQL statements and even C# operations. What is included in a SqlModelMapper transaction (no matter explicit or implicit) are identified by a variety of "track" methods:

  • Methods for tracking models: TrackCreate; TrackDelete; TrackCreateRange; TrackDeleteRange; TrackUpdate; Track (modelEntry); TrackUpdateRange; TrackRange
  • Methods for tracking SQL CUD: TrackSqlCUD; TrackDeleteByKey; TrackSqlBuilder
  • Methods for tracking master-detail: TrackMaster; TrackDetail; TrackDetails
  • Method for tracking action: Track

Other Highlights

  • Simple, minimal coding

    Simple to code advanced functionality, and data access is in models to minimize maintainance efforts.

  • Type-safe queries

    .NET objects are used as query criteria in a type-safe manner, and testing APIs are provided to verify SQL.

  • Loose relationships

    Relationships are defined while coding (not pre-defined) and are only persist for a particular query.

    Fast performance

  • There is little overhead compared to ADO.NET, and queries, updates, and actions are executed in bulk.