We will take a look into the Object dependencies before digging in more.
Consider a scenario of fetching an employee details and show display in UI. Let us say create a Business logic layer class named EmployeeBAL and a data access layer class named EmployeeDAO

public class EmployeeDao
{
//Some code
}

public class EmployeeBAL
{
var employeeDAO = new EmployeeDao();
//Some code
}

From the above code you will notice one thing that we are creating EmployeeDAO instance inside the Business logic layer class. So here comes the dependency

What is wrong if we have a dependency?

Think about whether your code is unit testable. We cannot fully unit test the EmployeeBAL as it has a dependency on Employee DAO. So we can say as long as the composition of the DAO exists within the BAL we cannot unit test the EmployeeBAL.

You will also notice one more thing here; with this type of implementation you will see a high coupling of BAL and DAL.

How to make it loose coupling?

The basic idea behind Dependency Injection is that you should isolate the implementation of an object from the construction of objects on which it depends.

Coming to the example, we should be isolating the implementation of EmployeeBAL object and the construction of the dependent EmployeeDAO object.

We will see how we can make loosely coupled objects in detail

Constructor based dependency injection

We will have to modify the EmployeeBAL to accept an EmployeeDAO instance within its constructor.

public class EmployeeDao
{
//Some code
}

public class EmployeeBAL
{
EmployeeDao employeeDAO;

public EmployeeBAL(EmployeeDAO employeeDao){
this.employeeDAO = employeeDao;
}
//Some code
}

Property based dependency injection

With property based injection we will have a public getter and setter Property of type EmployeeDao so that the dependency can be externally set.

public class EmployeeBAL
{
Public EmployeeDao EmployeeDataAccess{ get; set; }
}

var employeeBAL = new EmployeeBAL();
EmployeeBAL.EmployeeDataAccess = new EmployeeDao();

Wait!!!

The above ones are just some techniques of injecting the dependency. We are still yet to discuss one more interesting thing Unit Testing.

Are you agreeing that we have removed the DAO creation from the Business Logic EmployeeBAL? Yes it is good but it still depends on the actual instance of EmployeeDao.

Consider the below mentioned implementation of the same sample senarios

interface IDataAccess
{
//Some code
}

class EmployeeDao : IDataAccess
{
//Some code
}

public class EmployeeBAL
{
private IDataAccess dataAccess;
public BusinessFacade(IDataAccess dao)
{
dataAccess = dao;
}
}

You can notice we are doing a constructor dependency injection but most important thing here
is we are using Interface type than creating a strongly typed object.

The advantage that we are getting here is we can have an in memory data access object of
IDataAccess interface type and we can easily inject the dependency to the EmployeeBAL.
By this way we no need to have the actual database dependency.

Are you happy that we can unit test the BAL without the data access dependency?

Advantages of Dependency Injection

The primary advantages of dependency injection are:
Loose coupling
Centralized configuration
Easily testable

A delegate in C# is similar to a function pointer in C or C++. Using a delegate allows the programmer to encapsulate a reference to a method inside a delegate object. The delegate object can then be passed to code which can call the referenced method, without having to know at compile time which method will be invoked.

The signature of a single cast delegate is shown below:

delegate result-type identifier ([parameters]);

where:

• result-type: The result type, which matches the return type of the function.
• identifier: The delegate name.
• parameters: The Parameters that the function takes.

Delegates allow a clearer separation of specification and implementation. A delegate specifies the signature of a method, and authors can write methods that are compatible with the delegate specification.

Multicast delegates

With multicast delegate, it is just like a normal delegate but it can point to multiple functions so on invocation of such delegate it will invoke all the methods and functions associated with the same one after another sequentially.

Events:

Events are wrapper around the delegate. It sits on top of the delegate and provides only the necessary encapsulation so that the destination objects can subscribe to the Event and not have full control on the delegate object.

Events are declared using delegates. The delegate object encapsulates a method so that it can be called anonymously. An event is a way for a class to allow clients to give it delegates to methods that should be called when the event occurs. When the event occurs, the delegate(s) given to it by its clients are invoked.
We will consider an example implementation of Logger application, which can be used to log messages in Console, File or Database etc.

Logger Application ClassDiagram

public delegate void LogWriteDelegate(string message);

Next we will declare an Event of type LogWriteDelegate

public event LogWriteDelegate LogWriteEvent;

In our sample Logger the FileLogger and ConsoleLogger will subscribe or register to the above mentioned event so that when the Write method of logger is called the respective logic within the Write method of FileLogger and ConsolLogger will also gets invoked.

using (var logger = new Logger("testing", EntryType.Debug))
{
logger.LogWriteEvent += new Logger.LogWriteDelegate(consoleLogger.Write);
logger.LogWriteEvent += new Logger.LogWriteDelegate(fileLogger.Write);
logger.Write();
}

You can notice here a multicast delegate; the LogWriteEvent is being registered with Console and File log write methods.

While firing an Event within the Logger object, it is always a good practice to check whether the event is registered or not.

public void Write()
{
if (LogWriteEvent != null)
LogWriteEvent(ToString());
}

Here the LogWriteEvent holds the address of the methods console.Write and fileLogger.Write. When firing an event it will sequentially call the respective methods which are pre-registered to this Event.

Note: The Logger application is designed in such a way that in future you can have multiple implementations of Loggers. Right now we have Console and File Logger; if you are interested in implementing a Database logger we can create a new Class named DatabaseLogger which will implement ILogger interface. Provide necessary Write method logic so that it will log messages to database.

Ones you have done with the DatabaseLogger implementation, you just have to create an instance and register the event as we have done for Console and File Loggers.

Download Sample Logger Application

MIDP in general is one of the J2ME profile, a profile consists of Java classes. MIDP provides high-level API’s using which J2ME developer can easily develop applications, which is easy to use, highly graphical, with optimized for small computing devices such as Mobile phone. Also provides low-level user interface API’s giving the developers a control over the graphics and input. Thus reduces the development effort.

MIDP is targeted at a class of devices known as mobile information devices (MIDs). These are devices that have the following minimal characteristics:

1)      Enough memory to run MIDP applications

2)      A bit addressable display at least 96 pixels wide by 56 pixels high, either monochrome or color.

3)      A keypad, keyboard, or touch screen.

4)      Two-way wireless networking capability

Before we start up with MIDP 2.0 we will look over MIDP 1.0, which basically provides local storage, a user interface, networking capabilities and ability to operate in disconnected mode, ability to write applications in Java. But it was lacking end-to-end security and some other new features which is existing in MIDP 2.0

With MIDP 2.0, end-to-end security is now supported. MIDP 2.0 introduces the security concepts of application signing and privileged domains. With application signing applications can be trusted or not based on the ability to corroborate, via the use of a X.509 digital certificate, the application’s origin and integrity. These new features protect the device against unauthorized applications accessing data and functions. Also standard security protocols such as HTTPS, TLS/SSL and WTLS allows for secure transmission by encrypting the data. It is important to understand that MIDP in general is targeted at cell phones and low-end PDAs

The new MIDP 2.0 also includes support for an enhanced user interface API that allow developers create more functional and attractive business or consumer applications with less effort. It also includes new gaming and media APIs that can be used for business-applications.

MIDP 2.0 has expanded network connectivity support beyond HTTP, with support for UDP datagrams, TCP sockets, and serial port communication. Also a powerful feature called the push registry that activates dormant applications when new information is available. For example, with push support, server software can activate an application on the device to notify employees when a new calendar event has been scheduled or new sales lead generated, even if the application is not currently running.

The new Over-The-Air (OTA) application provisioning standardizes support for client-initiated download of applications over the wireless network. It allows users to find and install authorized applications wirelessly. It also allows application providers to track the installation and removal of applications for billing (or other) purposes.

MIDP also supports Short messaging service (SMS) and Cell Broadcast Service (CBS)

What does it MIDP provide?

The MIDP adds the following packages on top of the CLDC:

• Limit the use of memory

1. Avoid using object types.

2. Always use minimum data type for storing data.
3. Clean up the resources held by our program manually because even though garbage collector takes care of that we don’t know when it cleans up.
4. Allocate an object immediately before the object is used in the application rather than at the beginning of your application.
5. Set all references to objects to null once the application no longer needs the object. This decreases the memory application of the object to the minimum memory necessary to store the object references.
6. Reuse the objects instead of creating a new object; this reduces both the memory allocation and the need for processing power.
7. Reduce the exception thrown by our application because it reduces the memory.

• Offload computation to server.
• If application uses multiple screens make sure that each displays only relevant information.
• Application must accomplishes a task within 2 minutes otherwise the user is likely to turn off the mobile small computing devices.
• Limit the user input to few keystrokes.
• Avoid memory-consuming task such as communication, animation and sound.
• Reduce the data communication to minimum because users pay for transmission by byte usually in the range of 50,000 to 300,000 bytes per month.
• Pre load as many files as possible into a mobile small computing device in order to reduce data transmission.
• Always use a thread whenever an operation takes longer than a 10^th of a second to run because a thread requires fewer overheads than non-thread innovation methods.

The JABWT specification defines an optional J2ME package for Bluetooth wireless technology.

What is it?

The JABWT operates on top of the CLDC and is intended to extend the capabilities of profiles like the MIDP. JABWT use the Generic Connection Framework (GCF) defined in the CLDC specification for Bluetooth communication.

What does it provide?

JABWT consists of two packages.

These packages are separate optional packages so the CLDC implementation may include either of the packages or both of them.

The javax.bluetooth package provides an API for discovering devices and the services they provide. In addition it provides functionality for setting up services of your own and customization of local service records. Setting up L2CAP and RFCOMM connections is available through an extension to the Generic Connection Framework (GCF) from the CLDC.

The javax.obex provides an API for the OBject EXchange (OBEX) protocol. This package is not implemented on the Nokia 6600 smartphone. It is not tied to the Bluetooth API alone but is intended to be of more general use

Security

The JABWT does not define any security models itself. It depends on the security models available through the Bluetooth stack. However, it does define how the JABWT should interact with the lower layers in the Bluetooth stack responsible for security features. The device must have a Bluetooth Control Center (BCC) to which JABWT applications can direct their security requests.

BCC

The JABWT depends on a BCC implemented on the device. The BCC is the central authority for local Bluetooth device settings. It controls base security settings and provides lists of devices both known and trusted by the local device. The BCC is responsible for pairing devices and providing authorization for connection request. All of these functions must be included in the BCC.

The BCC may have other capabilities like setting the Bluetooth friendly-name of the device, setting timeouts for the baseband layer, determining how connectable and discoverable modes are set, resetting the local device or enumerating services on the local device. This BCC functionality is implementation dependent and may vary between OEMs an their devices. Some implementations may provide a GUI to the BCC while others provide hard-coded defaults in the BCC. For example, a headset will provide only defaults in the BCC since it does not have an input device or screen. When sending request to the BCC one should always check if the request was fulfilled by the BCC. One is not guaranteed that the BCC can fulfill the request at the given time.

A MIDlet is a Java program for embedded devices, more specifically the Java ME virtual machine. Generally, these are games and applications that run on a cell phone

A MIDlet requires a device that implements Java ME, MIDP to run. Like other Java programs, MIDlets have a “compile once, run anywhere” potential. MIDlet distributions also consist of a .jad file describing the contents of the JAR file.

A MIDlet has to fulfill the following requirements in order to run on a mobile phone:

• The main class needs to be a subclass of javax.microedition.midlet.MIDlet

• The MIDlet needs to be packed inside a .jar file (e.g. by using the jar-tool)

• The .jar file needs to be pre-verified by using a preverifier.

• In some cases, the .jar file needs to be signed by the mobile phone’s carrier.

MIDP Applications (MIDlets) and MIDlet Lifecycle

The applications written for mobile information devices such as cellular phones and pagers are called MIDlets. Like applets, MIDlets are controlled by the software that runs them. In the case of an applet, the underlying software is a browser or the applet viewer tool and in the case of a MIDlet, the underlying software is the cell phone or two-way pager device implementation that supports the CLDC and MIDP. A MIDlet is a well-behaved MIDP application, which lives within the resource constraints, which runs and terminates when requested.

All the devices, which support MIDP, are supposed to have a device-specific Application Management Software that takes care of installing, managing and removing MIDlets interactively.

MIDlet lifecycle

MIDlets move through a well-defined lifecycle consisting of five phases. It is the task of the Application Management Software to move MIDlets through these phases:

• Retrieval – The AMS retrieves the MIDlet from some source and reads the MIDlet into the device’s memory. The medium through which the MIDlet is downloaded depends on the device. It could be through a serial cable, an IRDA port, or a wireless network.
• Installation – Once the MIDlet is downloaded, the AMS installs the MIDlet on the device. During the installation process, the MIDP implementation verifies that the MIDlet does not violate the device’s security policies.
• Launching – A MIDlet is launched when a user selects it using the interface provided in the device. At this point, the MIDlet enters the KVM and the lifecycle methods of the MIDlet are invoked.
• Version Management – The AMS keeps track of all the MIDlets that are installed on the device including their version numbers. This information is used to upgrade a MIDlet to its new version.
• Removal – The AMS removes a MIDlet and cleans up the related resources from the memory.

A MIDlet can be in one of the three states after the Application Management Software launches it:

• Paused A MIDlet enters the Paused state once it is created and initialized by the AMS. It can also enter this state when it is Active.
• Active this state means the MIDlet is running normally. A MIDlet goes to the Active state from the paused state if there are no runtime exceptions during its initialization.
• Destroyed this state means the MIDlet has released all its resources and is terminated. A MIDlet can reach this state either from the paused state due to a runtime exception during its initialization or from the active state when the user has chosen to close the application.

MIDlet suites:

MIDlets are usually available through MIDlet suites. A MIDlet suite consists of two files, a .jar and a .jad file. The Java ARchive (JAR) file contains your compiled classes in a compressed and preverified fashion. All MIDlets must be preverified. This means that a checksum is computed, enabling the resource-constrained MID to easily check the integrity of the jar-file (using only a few hundred bytes of memory). Several MIDlets may be included in a MIDlet suite. Hence, the JAR file will contain all these MIDlet classes.

The Java Application Descriptor (JAD) file is a plain text file containing information about your MIDlet suite. All MIDlets must be named in this file, the size of the JAR file must be included (and be correct!) and the URL to the JAR file must be present. In addition, the MIDlet suite version number is included here. This is essential information for a MID. If the suite is already installed, it will know if a newer version is available. The size of the JAR file is important information, the MID can determine if there is enough memory available to install the MIDlet suite.

Every MIDLet contains 3 abstract methods that are called by the application manager to manage the life cycle of MIDLet. These abstract methods are startApp(), pauseApp(), destroyApp ( boolean unconditional)

public class Mymidlet extends MIDLet{

public void startApp(){

}

public void pauseApp(){

}

public void destroyApp( boolean unconditional ){

}

}

What does a JAD file contain? Why it’s required?

The JAD file is used by the application manager to know whether the MIDLet suite can be implemented on the device.

There are five required system attributes for a JAD file.

1. MIDLet Name.
2. MIDLet Version.
3. MIDLet – vendor.
4. MIDLet-n.
5. MIDLet-Jar-URL.

An Example of JAD File:

MIDLet-Name: Best MIDLet

MIDLet-Version: 2.0

MIDLet-Vendor: Mycompany

MIDLet-Jar-URL: http://www.mycompany.com/bestmidlet.jar

MIDLet-1: Best MIDLet, /images/BestMIDLet.png , Best.BestMIDLet

The MIDP Record Management System (RMS) provides a means to store application data that persists across invocations of a MIDlet. You can visualize the RMS record store as a very simple database, where each row consists of two columns: one containing a unique row identifier, the other a series of bytes representing the data in the record.

The unique row identifier is an integer value. The first entry will have the ID of 1, the next of 2, and so on. Row identifiers are not re-used if a row is deleted. That is, if we have three rows in a table with the IDs 1, 2, and 3, deleting ID 2 will remove this identifier permanently from the record store. If we were to add another row to this table, it would have an identifier of 4.

Record stores are identified by name. A name may consist of up to 32 characters, and all characters are case sensitive. No two record stores within a MIDlet suite (that is, a collection of one or more MIDlets packaged together) may contain the same name.

Each record store has a version number as well as a date/time stamp. Both values are updated whenever a record is added, replaced, or deleted.

Record management system provides a file system like environment that is used to store and maintain persistence in a small computing device. RMS is a combination of file system and Database management system that enables you to store data in columns and rows similar to the organization of data in a table of database.

The operations which can be performed in RMS are you can insert records, read records, search for a particular records and sort records stored in RMS.

Creating/Opening a Record Store:

openRecordStore() is called to create and open an existing record store. Accepts 2 parameters first parameter is a string-containing name of the record store, second parameter is a Boolean value (true) causes the record store to open if the record store already exists or else it will create.

RecordStore rs = RecordStore.openRecordStore (“MyAppointments”, true);

Here “MyAppointments”is the Record store name

Inserting records:

The MIDlet invokes the addRecord() method of javax.microedition.rms.RecordStore class to insert a new record into the record store. This is a blocking atomic operation and returns the recordId for the new record. The record is written to persistent storage before the method returns.

public int addRecord(byte[] data, int offset, int numBytes) inserts a record represented by an array of bytes data with offset as its starting index and numBytes as its length.

String appt = “new record”;

byte bytes[] = appt.getBytes();

rs.addRecord(bytes,0,bytes.length);

Updating Records in a Record Store:

Updating a particular record involves getting a handle for that record and setting new information.

public int getRecord(int recordId, byte[] buffer, int offset) returns the data stored in the given record in the byte array represented by buffer. public byte[] getRecord(int recorded) returns a copy of the data represented by recordId. public void setRecord(int recordId, byte[] newData, int offset, int numBytes) sets new information, a stream of bytes (newData) with offset as its starting index and numBytes as its length, at the record location represented by recordId.

String newappt = “update record”;

Byte data = newappt.getBytes();

Rs.setRecord(1, data, 0, data.length());

Closing a record store:

Internal resources are utilized to make an open record store available to MIDlets with in a MIDlet suite. You can reuse the resources utilized by the record store by closing the record store, which you don’t need closeRecordStore() method is used to close the record store.

Rs.closeRecordStore();

Deleting a Record Store:

A record store can be deleted by using deleteRecordStore(String). It requires one parameter which is a string containing the name of the record store.

RecordStore. deleteRecordStore(“MyAppointments”);

Writing Mixed Datatypes Into A RecordStore:

Private RecordStore recordstore=null;

Try

{

byte [] outputRecord;

String outputString=”First Record”;

int outputInteger= 15;

Boolean outputBooelan=true;

ByteOutputStream outputStream=new ByteOutputStream ();

DataOutputStream outputDataStream=new DataOutputStream(outputStream);

outputDataStream.writeUTF (outputString);

outputDataStream.writeUTF(outputInteger);

outputDataStream.writeUTF(outputBooelan);

outputDataStream.flush();

outputRecord= outputDataStream.toByteArray ();

recordStore.addRecord (outputRecord,0,outputRecord.length);

outputStream.close();

OutputDataStream.close ();

}

catch (Exception error)

{

// handle proper exceptions…

}

Reading Mixed Datatypes From A RecordStore:

Try

{

String inputString=null;

int inputInteger= 0;

boolean inputBooelan=false;

byte [] byteInputData= new byte[100];

ByteArrayInputStream inputStream=new ByteArrayInputStream(byteInputData);

DataInputStream inputDataStream=new DataInputStream (inputStream);

for ( int i=0;recordstore.getnumRecords(); i++)

{

recordstore.getRecord (i, byteInputData, 0);

inputString=inputDataStream.readUTF();

inputBooelan= inputDataStream.readBoolean();

inputInteger = inputDataStream.readInt();

inputStream.reset();

}

inputStream.close();

inputDataStream.close();

}

catch (Exception error)

{

// handle proper exceptions…

}

Configurations, Profile and Optional packages are 3 major concepts.

Configurations:

A configuration is a complete Java runtime environment, consisting of three things:

1. A Java virtual machine (VM) to execute Java byte code.
2. Native code to interface to the underlying system.
3. A set of core Java runtime classes.

To use a configuration, a device must meet certain minimum requirements as defined in the configuration’s formal specification. Although a configuration does provide a complete Java environment, the set of core classes is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by configuration implementor. In particular, configurations do not define any user interface classes.

J2ME defines two configurations, the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC is for very constrained (limited) devices — devices with small amounts of memory and/or slow processors. The VM used by the CLDC omits important features like finalization, while the set of core runtime classes is a tiny fraction of the J2SE core classes, just the basics from the java.lang, java.io and java.util packages, with a few additional classes from the new javax.microedition.io package. The CDC, on the other hand, includes a full Java VM and a much larger set of core classes, so it requires more memory than the CLDC and a faster processor. The CDC is in fact a superset of the CLDC. We’ll discuss the configurations in detail in the next two articles in this series.

Profiles:

A profile adds domain-specific classes to a configuration to fill in missing functionality and to support specific uses of a device. For example, most profiles define user interface classes for building interactive applications.

To use a profile, the device must meet all the minimum requirements of the underlying configuration as well as any additional requirements mandated by the profile’s formal specification.

There are several profiles in various stages of development. The first profile to be released was the Mobile Information Device Profile (MIDP), a CLDC-based profile for running applications on cellphones and interactive pagers with small screens, wireless HTTP connectivity, and limited memory. Another CLDC-based profile under development is the Personal Digital Assistant Profile (PDAP), which extends MIDP with additional classes and features for more powerful handheld devices. In terms of CDC-based profiles, the Foundation Profile (FP) extends the CDC with additional J2SE classes, the Personal Basis Profile (PBP) extends the FP with lightweight (AWT-derived) user interface classes and a new application model, and the Personal Profile extends the PBP with applet support and heavyweight UI classes.

Optional Packages:

An optional package is a set of APIs in support of additional, common behaviors that don’t really belong in one specific configuration or profile. Bluetooth support, for example, is defined as an optional package. Making it part of a profile wouldn’t work, because none of the behaviors of a profile can be optional — if a device supports a profile, it must support the entire profile — and that would limit the profile to Bluetooth-enabled devices.

Optional packages have their own minimum requirements, of course, just like configurations and profiles. Optional packages also have specific dependencies on a particular configuration and/or one or more profiles — they do not define a complete runtime environment, just sets of related APIs.

There are many optional packages in development, including the RMI Optional Package, which adds RMI support to CDC/FP-based profiles, the Java APIs for Bluetooth, which adds Bluetooth support to CLDC-based profiles, and the JDBC Optional Package for CDC/Foundation Profile, which defines a subset of JDBC (database access APIs) for use with CDC/FP-based profiles. Again, we’ll be covering these later on in the series as the need arises.

The CLDC Specification:

The CLDC is defined by a specification that has passed through the Java Community Process (JCP)

The CLDC specification defines three things:

1. The capabilities of the Java virtual machine (VM), which is not a full-featured Java VM.
2. A very small subset of the J2SE 1.3 classes.
3. A new set of APIs (application programming interfaces) for input/output called the Generic Connection Framework.

It’s also important to understand what the CLDC does not define. The CLDC does not define any APIs related to user interfaces. The CLDC does not define how applications are loaded onto a device or how they are activated or deactivated. These and other things are defined by the J2ME profiles that use the CLDC as their base. So while it’s true that the CLDC does define a complete Java runtime environment, the additional APIs defined by a profile or supplied by the vendor are really necessary to build useful applications.

The Virtual Machine:

The Java VM used in the CLDC is restricted in certain important ways when compared to a full-featured J2SE VM. These restrictions allow the VM to fit the memory and power constraints of the small devices that the CLDC target: the CLDC VM and classes can fit in 128K of memory. The primary restrictions on the VM are:

1. No floating point types.
2. No object finalization or weak references.
3. No JNI or reflection (hence no object serialization).
4. No thread groups or daemon threads (note that threads are supported, just not thread groups).
5. No application-defined class loaders.

Note that CLDC 1.1 relaxes some of these restrictions, in particular reenabling support for floating point types and weak references.

In addition to the above restrictions, the CLDC also requires class verification to be done differently. Class files are processed by an off-device class verifier, a process called preverification. At runtime, the VM uses information inserted into the class files by the preverifier to perform the final verification steps. Files that have not been processed by the preverifier are not loaded since they cannot be verified.

The J2SE Subset:

The subset of J2SE 1.3 included in the CLDC consists of classes from these three packages:

1. java.lang
2. java.io
3. java.util

Only selected classes from each package are included: for example, the java.util.Vector and java.util.Hashtable classes are included, but none of the collection classes are. The largest package is the java.lang package, which defines the classes that are fundamental to any java application, classes like java.lang.Object or java.lang.Integer. The java.io subset only includes abstract and memory-based classes and interfaces like java.io.DataInput or java.io.ByteArrayInputStream. The java.util subset only includes a few utility classes.

Some of the classes are subsets of their J2SE equivalents. Configurations are allowed to remove unnecessary methods or fields, but they cannot add new public or protected methods or fields.

“Association represents the static relationship shared among the objects of two classes. “So any relationship between object of two classes is called association.

An association says there is some kind of dependency between the objects. It can either be a weak or Strong dependency.

Consider an example of Teacher and Student classes. Multiple students can associate with single teacher and single student can associate with multiple teachers. This is a kind of a weak relationship because there is no ownership between the student and teacher and the life cycle are maintained by themselves.

Composition

Composition is specialized form of aggregation and we can call this as a “life and death” relationship. It is a strong type of aggregation. Child object does not have their life-cycle and if parent object deletes all child objects will also be deleted.

Consider an example of a set of classes Engine and Car. The object Engine is said to be composed with in the Car object as the Engine cannot leave without the Car object and the relationship is said to be whole because the Engine is a part of the Car object. Here the life cycle of Engine is managed by the Car object. If the Car gets destructed the associated composite object like Engine will also get destroyed.

Thus a composition relationship specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier.

public class Engine
{
. . .
}

public class Car

{

Engine e = new Engine();

…….

}

Yet another example for Composite relationship is, consider a set of classed Person, Leg and Hand. The objects Leg and Hand are composed within the Person object. The life cycle of Leg and Hand objects are maintained by Person object. Also you can see the Leg and Hand object cannot leave independently without the Person object. And note there is a strong relationship of Leg and Hand object with the Person.

Aggregation

The difference between aggregation and composition is the object which can exists independently uses aggregation and an object that has no meaning outside of the relationship uses composition

Let’s take an example of Department and teacher. A single teacher cannot belong to multiple departments, but if we delete the department, the teacher object will not destroy. We can think about “has-a” relationship.

Let us take another example of Company and Employee classes. The employee is said to be aggregated with the Company. The Employee is working for a company and has a relationship with the company.  The employee object can still survive even if say the Company object does not exists.

Conclusion

I will conclude here by taking a real world example which has aggregation and compositions.

Consider a scenario of a University which owns various departments (e.g., physics, chemistry) and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors. In addition, a Professor could work in more than one department, but a department could not be part of more than one university.

AutoMapper is an object-object mapper. Object-object mapping works by transforming an input object of one type into an output object of a different type.

When to use Automapper?

Here is one Sample scenario. Assume we have a domain model say a Customer entity and we are planning to show a list of Customers in a UI, for that, we need a much lighter object say CustomerViewModel, which has a list of Customer objects that can be used to bind the controls in UI layer.

Would you like to have something that will do mapping from Customer to the CustomerViewModel automatically?

Of course, you do, especially if you have another situation like mapping of heavy data objects into DTO objects which are considered to be sent though the wire.

How do I use AutoMapper?

First, you need both a source and destination type to work with. The destination type’s design can be influenced by the layer in which it lives, but AutoMapper works best as long as the names of the members match up to the source type’s members. If you have a source member called “FirstName”, this will automatically be mapped to a destination member with the name “FirstName”.

Once you have your types, and a reference to AutoMapper, you can create a map for the two types.

Mapper.CreateMap<Order, OrderDto>();

The type on the left is the source type, and the type on the right is the destination type. To perform a mapping, use the Map method.

OrderDto dto = Mapper.Map<Order, OrderDto>(order);

AutoMapper also has non-generic versions of these methods, for those cases where you might not know the type at compile time.

Where do I configure AutoMapper?

If you’re using the static Mapper method, configuration only needs to happen once per AppDomain. That means the best place to put the configuration code is in application startup, such as the Global.asax file for ASP.NET applications. Typically, the configuration bootstrapper class is in its own class, and this bootstrapper class is called from the startup method.

Samples and DLL’s:

http://www.codeproject.com/KB/library/AutoMapper.aspx

http://automapper.codeplex.com/