Enterprise Application Architecture

1. Enterprise Application Architecture • Divide a complex system into layers • e.g. TCP, IP, Ethernet, physical layer • 2- layers • 1990s, Client-server, 2 layers • Presentation + Database • 3- layers (or 3-tiers) structure • An expanded domain logic layer • Presentation, Domain Logic and Database

2. Presentation Layer • Template View • The simplest way • Generate a HTML page dynamically by embedding markers into a static HTML page • Using languages like JSP, ASP, or PHP • MVC model • For more complex systems

3. Service Layer • Add a service layer to define application’s boundary • So as to support different interfaces (GUI, web, …) • e.g. use a Façade object to connect to a GUI client Web Service Layer Domain Model GUI Database

4. One common way of handling complicated applications • Front Controller • A controller that handles all requests • Delegate the work to a command object

5. Big problem - domain model to database mismatch • Data is typically stored in the form of tables in relational database • Fundamental differences between OO model and relational model • Relational model has no concept of inheritance • Tables in relational model are related by keys, classes in OO model are related by references • Keys must be explicit (need a field to contain) while references can be implicit • The impedance mismatch problem • Difficult to map an object to a table directly

6. Inheritance problem • How to store the object hierarchy to a relational database? Lendable title Book Video format DVD region

7. Object to table mapping problem • Table per class • Map each class to a table • Table per Concrete Object • Map each concrete object to a table • Single table for the entire class family • Map everything into a single table • None of them is satisfactory

8. Map each class to a table • Pros • Classes can be modified independently • Cons • To rebuild an object, need to join the data from multiple tables • Tables are related by keys, keeping track of the key can be complex <<Lendable>> title <<Video>> format <<DVD>> region

9. Map each concrete object to a table • Pros • Simple • Cons • If a field in the superclass is changed, then all subclasses’ tables have to be changed too • Redundancy between tables, which may lead to inconsistencies • Defeat the purpose of normalization <<Lendable>> title <<Video>> title format <<DVD>> title format region

10. Single Table Inheritance • Merge all fields in all classes into one table • Advantages • Simple, changes can be done in one table • Disadvantage • Large number of null columns, waste storage • Defeat the purpose of normalization Type title format region aLendable A111 -- -- aDVD Casablanca Color 3

11. Identity problem • Two objects can have EXACTLY the same states, but still they have different identity • The identity of objects come naturally as they are referenced by different pointers • Often you don’t need a special field to store the identity • e.g. A Borrower has-a collection of Books • Borrower knows Book via the reference but not the other way round (Book does not know the Borrower)

12. Tables for Borrower and Book Borrower table Book table

13. Identity problem • In RDBMS, Book needs to know the Borrower (the opposite of OO model) • To write the Books back to database, Book needs identify the borrower uniquely by the BorrowerID • The primary key in Borrower table • The foreign key in Book table • O/R (object to relational) mapping • Need to add an extra attribute in the Book object for the foreign key • This field is called Identify Field

14. Foreign key mapping • This is not enough • class Book … string title; } • An extra attribute to store the key for the database • class Book … string title; string BorrowerID; //foreign key field }

15. O/R mapping (ORM) tool • To bridge the gap between OO model and relational database automatically • e.g. Hibernate for Java and NHibernate for .NET • Translating objects to forms which can be stored in the database • Ideal case, the object model sees no SQL, and the underlying relational database • Developers see a virtual objects store • One of the most active research areas in computer science

16. Limitations of O/R Mapping • Object to Table mapping problem, as mentioned before • Automatic translation from objects to SQL efficiently is hard • O/R mapping tools may solve 80% of the problems, they therefore also offer OQL (object query language) to take care of difficult cases • Efforts in program the database schema into the ORM

17. So what can we do about this impedance mismatch? • Ted Neward listed 6 solutions in the following site • http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx • Acceptance of O/R-M limitations – use automated O/R mapping tools • Wholehearted acceptance – used OODBMS • Abandonment – give up OO completely • Integration of relational concepts into frameworks • Manual mapping – constructs object using manually coded SQL • Integration of relational concepts into the languages – e.g. LINQ in C# 3.0

18. OODBMS (OO Database Management System) • Bypass the O/R mapping problem, object is stored as it is, not in the form of table • e.g. db4o (db for objects) • Can search and retrieve objects directly, no need to join tables • Very fast, high performance • But OODBMS is almost dead in commercial applications • Why?

19. Problem with OODBMS • Database is shared by many departments in a company • Different department views/uses the database differently • Data in OODBMS is designed for a particular object model, i.e., a particular view point • Tight coupling between database schema and the developer’s model is a bad thing, other department may view the structure of the data in different way

20. Problem with OODBMS • RDBMS concerns only about storing the data efficiently via normalization, without regard to any particular object model (neutral to any application), therefore is an advantage • Nevertheless, OODBMS holds the record for the largest database (Stanford Linear Accelerator Centre – 1 Petabyte)

21. Abandonment • Abandonment • Based completely on relational model • No objects, therefore no impedance mismatch • Most applications have a lot to do with CRUD (create, read, update, delete) • RDBMS + transaction script (for business logic) • Transaction script • e.g. PHP, ASP, JSP, CGI • A single procedure for each user initiated action

22. Transaction script • Disadvantage • No separation between presentation and business logic layers • Changes in database or business logic will affect many scripts • Suitable for simple applications only

23. Integration of relational concepts into frameworks • Using objects that is more relational in nature • e.g. Recordset in ADO.NET and JDBC • Recordset is like a table from SQL query (View) • Advantages • Can be processed offline from the database • UI can be updated directly • Platform supports smart data-aware GUI updating • Disadvantages • Tight coupling between database schema and the GUI • Suitable only for CRUD applications

24. Manual mapping • Solve the problem by writing SQL to access the tables, returning the objects • But too much code to write and maintain • E.g. Row Data Gateway • Each gateway object represents a row in the database table and has methods that encapsulate the SQL • class BorrowerGateway … { Borrower find(borrowerID) {…} } • find() encapsulates the SQLs and return a Borrower object

25. Table Data Gateway • To get the booklist for Borrower using Row Data Gateway takes multiple database read • Table Data Gateway is an object that reads multiple records and returns a table in one go • More efficient

26. Data Mapper • For more complex situation • A direct mapping between database record and domain object may not be possible • Need to add an layer to carry out the mapping • Data Mapper = an intermediate object that maps between domain object and the relational database

27. Integration of relational concepts into the languages • Call-Level Interfaces (CLI) • ODBC, JDBC, ADO.NET • CLI provides an object-like API by passing a SQL query as a string literal into the library, and returning the result of the query • Problems • Verbosity • SQL code scattered across the application, difficult to change the database schema in a manner independent of the object model • OK for smaller projects, but for large systems, need to add comment tags to the SQL in the code so that they can be located more easily

28. Integration of relational concepts into the languages • Recent approach • Integrate query language directly into traditional O-O languages • e.g. LINQ project for C# and Visual Basic • LINQ (Language INtegrated Query) • Can query anything that has structure • Data in a container • RDBMS • XML • The main feature in C# 3.0

29. LINQ • A unified language for making query to different structures using C#-like syntax • Compiler turns LINQ’s statements into an Abstract Syntax Tree (see Interpreter pattern) • The tree is translated into specific queries by various add-on programs, e.g. • LINQ for SQL (previously DLINK) – for RDBMS • XLINQ – for XML data LINQ LINQ for SQL RDBMS Abstract Syntax Tree XLINQ XML

30. Advantages • Since LINQ is part of the language (C# ver3.0), the syntax of the query language can be checked during compile time and not during run time • Strings embedded in CLI calls cannot be checked by compiler • Strong type checking can be performed by the compiler, which cannot be done by O/R mappers as they have no control on the C# compilers • LINQ does not deal with O/R mapping, it is only an extension to the compiler • LINQ to SQL generates the SQL code, and is therefore a kind of O/R mapper • Differentiation between O/R mappers in the future will be based on how well they implement the translation from LINQ to SQL

31. Example: define the class to table mapping [Table(Name=“Borrower")] public class Borrower { [Column(DbType="nvarchar(32) not null",Id=true)] public string Name; [Column] public int BorrowerID; } [Table(Name=“Book")] public class Book { [Column(DbType="nvarchar(32) not null", Id=true)] public string Title; [Column] public int BorrowerID; [column] public int BookID; }

32. A list of borrowers and the borrowed books // establish a query context connection to ADO.NET DataContext context = new DataContext( connectionString ); // grab variables that in the remote tables Table<Borrower> user = context.GetTable<Borrower>(); Table<Book> books = context.GetTable<Book>(); // build the query, query is anonymous class var query = from u in user, b in books where u.BorrowerID == b.BorrowerID select new { u.Name, b.Title }; // execute the query foreach (var item in query) Console.WriteLine("{0} {1}", item.Name, item.Title);

33. Ref • The LINQ Project – Don Box and Anders Hejlsberg • http://msdn2.microsoft.com/en-us/library/aa479865.aspx • Comparing LINQ and Its Contemporaries – Ted Neward • http://msdn2.microsoft.com/en-us/library/aa479863.aspx