barcode vb.net 2008 Writing and mapping classes in Visual C#.NET

Create Code 39 Extended in Visual C#.NET Writing and mapping classes

POCO basics for rich domain models The concept of object identity and its mapping Mapping class inheritance Association and collection mappings

The Hello World example in chapter 2 gave a gentle introduction to NHibernate; but we need a more thorough example to demonstrate the needs of real-world applications with complex data models. For the rest of the book, we explore NHibernate using a more sophisticated example application an online auction system. We start our discussion of the application by introducing a programming model for persistent classes. First, you ll learn how to identify the business objects (or entities) of a problem domain. You ll create a conceptual model of these entities and their attributes, called a domain model. You ll implement this domain model in C# by creating a persistent class for each entity, and we ll spend some time exploring what these .NET classes should look like.

You ll then define mapping metadata to tell NHibernate how these classes and their properties relate to database tables and columns. We covered the basis of this step in chapter 2. In this chapter, we give an in-depth presentation of the mapping techniques for fine-grained classes, object identity, inheritance, and associations. This chapter therefore provides the beginnings of a solution to the first generic problems of ORM listed in section 1.3.1. For example, how do you map fine-grained objects to simple tables Or how do you map inheritance hierarchies to tables We start by introducing the example application.

The CaveatEmptor online auction application demonstrates ORM techniques and NHibernate functionality; you can download the source code for the entire working application from the website http://caveatemptor.hibernate.org/. The application will have a console-based user interface. We don t pay much attention to the user interface; we concentrate on the data-access code. In chapter 8, we discuss the changes that would be necessary if you were to perform all business logic and data access from a separate business tier. And in chapter 10, we discuss many solutions to common issues that arise when integrating NHibernate in Windows and web applications. But let s start at the beginning. In order to understand the design issues involved in ORM, let s pretend the CaveatEmptor application doesn t yet exist and that you re building it from scratch. Your first task is analysis.

A software development effort begins with analysis of the problem domain (assuming that no legacy code or legacy database already exists). At this stage, you, with the help of problem domain experts, identify the main entities that are relevant to the software system. Entities are usually notions understood by users of the system: Payment, Customer, Order, Item, Bid, and so forth. Some entities may be abstractions of less concrete things the user thinks about (for example, PricingAlgorithm), but even these are usually understandable to the user. All these entities are found in the conceptual view of the business, which we sometimes call a business model. Developers of object-oriented software analyze the business model and create an object model, still at the conceptual level (no C# code). This object model may be as simple as a mental image existing only in the mind of the developer, or it may be as elaborate as a UML class diagram (as in figure 3.1) created by a Computer-Aided Software Engineering (CASE) tool like Microsoft Visio, Sparx Systems Enterprise Architect, or UMLet. This simple model contains entities that you re bound to find in any typical auction system: Category, Item, and User. The entities and their relationships (and perhaps

0..*

0..*

their attributes) are all represented by this model of the problem domain. We call this kind of model an object-oriented model of entities from the problem domain, encompassing only those entities that are of interest to the user a domain model. It s an abstract view of the real world. We ll refer to this model when you implement your persistent .NET classes. Let s examine the outcome of the analysis of the the CaveatEmptor application s problem domain.