Using VITA in an Existing Project

Highlights

  • VITA as an ORM does not require a full commitment for all data access operations on a new project. If you have a large older application that is in a continuous development, you can easily start using VITA for some new features, or switching existing parts of the application.
  • VITA can run side-by-side with your existing data access layer (DAL) - all you need is a singleton of an EntityApp created at startup and saved in a global static field.
  • Do not be scared by the fact that VITA CAN update the database model from the entity model - if this functionality goes against the established process for an existing application - you can turn OFF this feature completely.
  • VITA uses CRUD stored procedures by default but you can switch to using plain SQLs if it better fits your case.
  • VITA can run against a small part of a bigger data model. VITA does not require you to have your entire database represented in the entity model, and does not need to take over all of the data access in an existing app, all at once.
  • Low entry barrier - VITA is a low-demanding framework in terms of initial learning and coding effort. It is easy to start writing data access code - IEntitySession is a simple interface - and you have LINQ for creating complex queries.
  • Low startup time - even for bigger models with 100+ tables VITA's startup time is in milliseconds range. If you have only a dozen of tables to manage, the startup delay is insignificant.
  • Efficient data access at low cost - VITA lets you drastically cut the time and effort on coding data access operations while providing very efficient data access layer.

Scenario 1. DB-first path, no CRUD stored procedures

You have a new feature that involves a limited set of existing tables within a bigger solution. Modifying database schema (including creating CRUD stored procedures) is not an option.
All tables exist already, so you start by generating entity model interfaces using vdbtool - details here: DB-First Scenario.
Vdbtool does not provide fine-grained filtering options for selecting only the tables you need, only by the schema. As a result you may end up with entity interfaces generated for all tables in the database. That's not a big problem, just locate those you need and copy/paste them into a separate cs file. If the tables/entities you select reference other non-selected tables, follow instructions here.
The code generator also generates other startup code you need - EntityModule and EntityApp classes, and a sample startup code. Put this code into your existing solution, call the VITA initialization code at startup of you app, and save the EntityApp-derived instance in a global static variable. Use this object to open entity sessions and perform data access in your custom feature code.
You need to make a few adjustments in the initialization code, particularly the constructor of DbSettings instance.
Here is the code generated by vdbtool:
    var dbSettings = new DbSettings(driver, DbOptions.Default, connString, modelUpdateMode: DbModelUpdateMode.Always);
      App.ConnectTo(dbSettings);
First, you need to change the value of modelUpdateMode to DbModelUpdateMode.Never, to tell VITA to NOT update the database model.
Secondly, as creating CRUD stored procedures in the database is not an option, you need to tell VITA to use the plain SQL for CRUD operations. You do it by turning off the flag in DbOptions flag set:
    var dbOptions = MsSqlDbDriver.DefaultMsSqlDbOptions &= ~DbOptions.UseStoredProcs; // for MS SQL
    var dbSettings = new DbSettings(driver, dbOptions, connString, modelUpdateMode: DbModelUpdateMode.Never);
    App.ConnectTo(dbSettings);

Scenario 2. Existing tables, OK to add CRUD stored procedures

The initial conditions are similar: the tables already exist in the database, you should not change them, but you can also add CRUD stored procedures for the tables you will be working with - using an established process of updating database model.
You start the same way as in the previous case, by generating the entity definitions using vdbtool, then selecting the entities (interfaces) you need and embedding them and initialization code into your solution.
You do not need to drop the DbOptions.UseStoredProcs flag - VITA will be using CRUD stored procedures. To create these stored procedures in the target databases, you generate the DDL script using vdbtool, now in 'dbupdate' mode, details are here: Database Schema Update Scenarios. Because you are interested only in DDL creating stored procedures, you need to change the ModelUpdateOptions to include only 'UpdateStoredProcs' flag in the settings XML file.

    <ModelUpdateOptions>UpdateStoredProcs</ModelUpdateOptions>
Once you run the vdbtool, take the generated SQL scripts (whole bunch of 'CREATE PROCEDURE ...' SQLs) and push it into whatever SQL script management tool/process you use in your organization. The script will create the stored procedures on target servers (production, staging, or local databases on team members' machines), so your VITA-based code in the feature you write can start using these for database access.
You may allow VITA to create these CRUD procedures automatically at startup in dev/test databases, just to make it easier for other team members or QA. To implement this, you need to read the value for ModelUpdateMode in configuration file, so that it is still 'Never' for production servers, but 'Always' everywhere else. You also need to explicitly set the DbModelUpdateOptions value for DbSettings constructor to tell VITA to limit database schema updates to stored procedures:
    var dbOptions = MsSqlDbDriver.DefaultMsSqlDbOptions; // for MS SQL
    var dbSettings = new DbSettings(driver, dbOptions, connString, modelUpdateMode: DbModelUpdateMode.Always, modelUpdateOptions: DbModelUpdateOptions.UpdateStoredProcs);
    App.ConnectTo(dbSettings);

Scenario 3. New Tables

This is essentially a code-first scenario described here: VITA Quick Start Guide. The only difference is that you will be working with a part of the bigger database, and VITA code will be running side-by-side with the DAL code in the existing app. However, to account for this you do not need to do anything special. By default VITA ignores 'unknown' tables (unknown to VITA-based code, tables not present in the entity model). You can define new entities/tables with keys and indexes using entity interfaces. For pushing database updates, you have a range of options, described here: Database Schema Update Scenarios.
You can either let VITA create all objects automatically, or generate the DDL script and provide it to database administrators.
Note: the flag that controls the 'ignore others' behavior is in modelUpdateOptions parameter to DbSettings constructor; the value is DbModelUpdateOptions.DropUnknownObjects, and it is OFF by default, so VITA ignores all unknown other tables. This flag is useful when you are in active design phase, change data model often and want VITA to drop tables that you removed from the model.


Last edited Apr 21, 2015 at 5:39 PM by rivantsov, version 12

Comments

No comments yet.