http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
Thursday, October 15, 2009
Wednesday, October 14, 2009
Monday, July 27, 2009
Solid State Hard Drives
A solid state drive is a storage device that uses solid state memory to store data. While technically not a disk, a solid state drive will often be referred to as a solid state disk drive, or a solid state disk, in reference to the fact that, in some ways, it replaces the traditional hard disk drive. Hard disk drives have been a faithful servant to computing for many years. But with heads, platters, magnetic surfaces, spindles and an array of other complex moving parts, they are most certainly fallible. They can be slow, too: disks have to start spinning if they're not already doing so, then they have to get the head to the correct position on the disk to read or write the data. Add this to the physical problems occurring when a piece of dust or other foreign object gets into the mechanism, or when an impact jolts the drive, and we have a distinctly imperfect system. Solid state drives address many of these timing and structural problems inherent in the hard disk drive.
The principle behind solid state drives is that there should be no moving parts: no spinning platters, no moving heads. Data is split into word length pieces and stored in memory. It is then accessed almost instantaneously using unique system-wide addresses. This behaviour has been used in computer RAM for many years, but for a long time it was too expensive for manufacturers to consider using it as persistent storage in sufficient volumes to replace the hard disk drive.
Solid state disks use either NAND flash or SDRAM (non-volatile and volatile storage respectively). NAND flash is so-called because of the NAND-gate technology it uses and is common in USB flash drives and many types of memory card. NAND flash based drives are persistent and can therefore effectively mimic a hard disk drive. Synchronous dynamic random access memory (SDRAM) is volatile and requires a separate power source if it is to operate independently from a computer.
Solid state drives may be preferred over traditional disk drives for a number of reasons. The first advantage is found, as mentioned briefly above, in the speed of operation. Because hard disk drives need to be spinning for the head to read sectors of the platter, sometimes we have to wait for "spin up" time. Once the disk is spinning, the head must seek the correct place on the disk, and from there the disk must spin just enough so that the correct data is read. If data is spread over different parts of the disk (fragmented) then this operation is repeated until all the data has been read or written. While each individual operation only takes fractions of a second the sum of them may not. It is often the case that reads to and writes from the hard disk are the bottleneck in a system.
Because the information on solid state drives can be accessed immediately (technically at the speed of light) there is no latency experience when data is transferred. Because there is no relationship between spatial locality and retrieval speed, there is no degradation of performance when data is fragmented.
Consequences of the increased speed of writes for fragmented data include a much decreased application start up time: SanDisk, for instance, claim to have achieved Windows Vista start up times of around 30 seconds for a laptop with its SSD SATA 5000 2.5".
Solid state drives also enjoy greater stability over their disk counterparts. Because there are no moving parts there is less that can go wrong mechanically. Dust entering the device ceases to become a problem (and in any case solid state drives can be sealed air tight unlike disk drives which require a certain air cushion to function properly), and dropping the drive is less likely to cause damage to the data. There are no heads so head crashes are a thing of the past.
This speed and stability comes at a price, of course, and in early models prices of even the most modest of solid state capacities greatly surpassed that of the largest hard disks.
Solid state disks use either NAND flash or SDRAM (non-volatile and volatile storage respectively). NAND flash is so-called because of the NAND-gate technology it uses and is common in USB flash drives and many types of memory card. NAND flash based drives are persistent and can therefore effectively mimic a hard disk drive. Synchronous dynamic random access memory (SDRAM) is volatile and requires a separate power source if it is to operate independently from a computer.
Solid state drives may be preferred over traditional disk drives for a number of reasons. The first advantage is found, as mentioned briefly above, in the speed of operation. Because hard disk drives need to be spinning for the head to read sectors of the platter, sometimes we have to wait for "spin up" time. Once the disk is spinning, the head must seek the correct place on the disk, and from there the disk must spin just enough so that the correct data is read. If data is spread over different parts of the disk (fragmented) then this operation is repeated until all the data has been read or written. While each individual operation only takes fractions of a second the sum of them may not. It is often the case that reads to and writes from the hard disk are the bottleneck in a system.
Because the information on solid state drives can be accessed immediately (technically at the speed of light) there is no latency experience when data is transferred. Because there is no relationship between spatial locality and retrieval speed, there is no degradation of performance when data is fragmented.
Consequences of the increased speed of writes for fragmented data include a much decreased application start up time: SanDisk, for instance, claim to have achieved Windows Vista start up times of around 30 seconds for a laptop with its SSD SATA 5000 2.5".
Solid state drives also enjoy greater stability over their disk counterparts. Because there are no moving parts there is less that can go wrong mechanically. Dust entering the device ceases to become a problem (and in any case solid state drives can be sealed air tight unlike disk drives which require a certain air cushion to function properly), and dropping the drive is less likely to cause damage to the data. There are no heads so head crashes are a thing of the past.
This speed and stability comes at a price, of course, and in early models prices of even the most modest of solid state capacities greatly surpassed that of the largest hard disks.
Some results on web
Wednesday, March 04, 2009
Monday, March 02, 2009
Monday, February 23, 2009
Friday, February 20, 2009
Difference between Composition and Aggregation
Composition:
As we know, inheritance gives us an 'is-a' relationship. To make the understanding of composition easier, we can say that composition gives us a 'part-of' relationship. Composition is shown on a UML diagram as a filled diamond (see Figure 1).
If we were going to model a car, it would make sense to say that an engine is part-of a car. Within composition, the lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed along with it. So how do we express this in C#?
public class Engine{ . . . }
public class Car
{
Engine e = new Engine();
.......
}
As you can see in the example code above, Car manages the lifetime of Engine.
Aggregation:
If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example. For the past 12+ months I have been involved with the implementation of a CRM system, so I am going to use part of this as an example.
The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond (see Figure 2).
So how do we express the concept of aggregation in C#? Well, it's a little different to composition. Consider the following code:
public class Address{ . . .}
public class Person
{
private Address address;
public Person(Address address)
{
this.address = address;
}
. . .
}
Person would then be used as follows:
Address address = new Address();
Person person = new Person(address);
or
Person person = new Person( new Address() );
As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario does map quite nicely to the real world.
Refered from:http://www.c-sharpcorner.com/UploadFile/pcurnow/compagg07272007062838AM/compagg.aspx
As we know, inheritance gives us an 'is-a' relationship. To make the understanding of composition easier, we can say that composition gives us a 'part-of' relationship. Composition is shown on a UML diagram as a filled diamond (see Figure 1).
If we were going to model a car, it would make sense to say that an engine is part-of a car. Within composition, the lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed along with it. So how do we express this in C#?
public class Engine{ . . . }
public class Car
{
Engine e = new Engine();
.......
}
As you can see in the example code above, Car manages the lifetime of Engine.
Aggregation:
If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, we need an example. For the past 12+ months I have been involved with the implementation of a CRM system, so I am going to use part of this as an example.
The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond (see Figure 2).
So how do we express the concept of aggregation in C#? Well, it's a little different to composition. Consider the following code:
public class Address{ . . .}
public class Person
{
private Address address;
public Person(Address address)
{
this.address = address;
}
. . .
}
Person would then be used as follows:
Address address = new Address();
Person person = new Person(address);
or
Person person = new Person( new Address() );
As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario does map quite nicely to the real world.
Refered from:http://www.c-sharpcorner.com/UploadFile/pcurnow/compagg07272007062838AM/compagg.aspx
Sunday, February 15, 2009
Bookmarks Microsoft Project
Multiple Projects
http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=443
Beginning Tracking
http://pubs.logicalexpressions.com/Pub0009/LPMArticle.asp?ID=577
also can do a search http://pubs.logicalexpressions.com/Pub0009/LPMFrame.asp?CMD=Archives
provide keywords as Microsoft Project
author: Mike Glen. MVP
Subscribe to:
Posts (Atom)