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:

    • SnapObjects.Data
    • SnapObjects.Data.SqlServer
    • SnapObjects.Data.Oracle
    • SnapObjects.Data.PostgreSql
    • SnapObjects.Data.Odbc
    • SnapObjects.Data.AspNetCore

    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.

    Back to top Generated by Appeon