HIGHLIGHTS UML Modeling VS.NET Integration Data-Binding Schema Generation Database Browser Feature List

Use an Object Model to represent your application
We found that most programmers are familiar and comfortable with the way Microsoft Office Applications expose their functionality to programmers in form of an object model. With tangible® architect™, the architect in your team can design an object model in UML and let tangible architect generate its implementation including data access code. You can then add the business logic to that object model.
How a Persistent Object Model works
An object model has one root object, e.g. MyApplication, from which all other objects are accessible by navigating object relationships. The following diagram shows an object model for an addressbook application. The object model is used by some client code, and the object model automatically stores its data in a database - hiding the details of SQL programming from the developer. Each class in an object model is described by a C# interface from which it can be generated

 
Intelli-Sense and the XML Code Comments feature are available to the developer, as the object model is completely strong-typed. This makes writing client code against an object model easy. Have a look at a code snippet that opens a database connection and creates a few objects:

private CRM.IAddressBook theAddressBook; 

// instanciate the object model and connect to the database create
theAddressBook = new CRM.AddressBook(new ConnectionSettings("CRM_DB");

// Create a named Customer and a named Employee
CRM.ICustomer theCustomer1 = theAddressBook.Customers.CreateCustomer("Mr. Mayer");

// Create a service request bi-directionally linked to the customer
CRM.IServiceRequest theServiceRequest
    = theCustomer1.RequestedServiceRequests.CreateServiceRequest("Problem " + 
      "with TV in room");
theServiceRequest.IssueDate = System.DateTime.Now;
theServiceRequest.PriorityLevel = 2;

// link Employee to Customer
theCustomer1.ContactPersons.LinkEmployee(theEmployee1);

 
Using the navigational approach to retrieve objects from a database is natural when you think of business logic code that modifies an order and related items, or a treeview that displays a hierarchy of items. In addition, an object model provides query functionality so that specific objects can be retrieved directly just by specifying the desired object characteristics.
Where and how to put the business logic?
It is industry's best practice to separate business logic code and user interface code for two major reasons: First, the application is easier to maintain if business logic is concentrated in one dedicated layer rather than being distributed or hidden in event handlers of user interface elements. Second, in a Web and Client/Server enabled application, business logic must be commonly available and shared between WinForms and WebForms. The persistent object model is extensible and provides an ideal location for your business logic: User Classes. A User Class is generated for each C# interface description and inherits from a generated persistent base class, which provides the methods and implementation for data access. You can override the default implementation of the data access methods or add your own methods and event handlers to realize the business logic of your application as outlined in the following samples.

Sample Business Rules:

• Customer account numbers may only be assigned once
  We realize this by overriding the property AccountNumber in the User Class.
• Customer's average discount must be calculated
  We realize this by adding a method to the Customer User Class and Interface.  

Here is the code for the User Class "Customer":

[Persistent]
public class Customer : Persistence.PsCustomer, ICustomer
{
  // Internal Constructor of the AddressBook User Class
  internal Customer(object RootObject)
  : base(RootObject)
  {
  }

  public int AccountNumber
  {
    get
    {
       return base.AccountNumber;
    }
    set {
       if (AccountNumber != 0 )
       {
          throw new Exception("Account number may only be set once");
       }  else {
          base.AccountNumber = value;
       }
    }
  }

  public double GetAverageDiscount()
  {
   double averageDisc;
   // TODO: calculate average discount
   return averageDisc;
   }
}

Sample Business Rule 3: account numbers are assigned by an external system
We will realize this rule by adding a Customers_AfterCustomersCreate event handler to the parent class "Addressbook" using the tangible architect class wizard. Here is the implementation for the User Class Addressbook: 
 
/// This is the User Class for AddressBook
/// you can add your business logic here.
[Persistent,RootObject]
public class AddressBook : Persistence.PsAddressBook, IAddressBook
{
  // Constructor of the AddressBook User Class
  public AddressBook(ConnectionSettings connSettings)
  : base(connSettings)
  {
  }
  // The OnInit Method was automatically added by the Class Wizard
  // when you attach to the AfterCustomersCreate Event
  override public void OnInit()
  {
      AfterCustomersCreate += new CRM.ICustomerContainsCol.AfterCustomerCreateHandle
                                            (Customers_AfterCustomersCreate);
  }

  // This event handler assigns a valid AccountNumber that is requested from a ERP System
  private void Customers_AfterCustomersCreate(ICustomer inCustomer)
  {
     inCustomer.AccountNumber = ABAPHelper.getFreeAccountNumberFromSAP();
  }
}

Implementing your business logic directly in the user classes has several advantages. One of the biggest benefits is that your business rule implementation is directly attached to the object to which it relates. The User Classes represent the hand-written code of your business logic. This way, business logic can be clearly identified as it is not mixed up with data access code or user interface code.
tangible® architect™ ensures that all team members are up to date
How often did you have a bad day because you did not get notified by your team that a database field was relocated into another table or just renamed? How close did the latest UML Diagram match the real world implementation – and how long did it take you to find out what was really going on?
tangible® architect™ addresses these problems of team-communication by providing each team member with an appropriate representation of the design and several methods to change and communicate the design to other members: With tangible® architect™ a field can be changed or added directly in the C# interface specification, UML Diagram or using the tangible® architect™ class view wizards. In any case tangible® architect™ will assure that the generated database access code and schema reflect that change and that UML Diagrams will be updated. In addition, the User Interface Developers will easily detect that change in the tangible® architect™ class view. If someone tries to access a field that no longer exists, the C# compiler will warn the user – no matter if the Query API or a navigational approach to data access is being used.
Ease debugging using the object-oriented database browser
The object-oriented database browser of Microsoft® Meta Data Services™ is available to you for all persistent object models. This makes it easy to review and edit the data in the database. As the database is self-describing you don't even need the object model's accompanying DLL to use the browser. See for yourself: