Search Results

Keyword: ‘"Automatic Properties"’

Automatic Properties and StackOverflowException

January 14, 2008 2 comments

I’ve written a couple of times before about Automatic Properties, a tiny little feature that I have really come to enjoy. Remember that an Automatic Property looks something like this:

// An Automatic Property
public string FirstName { get; set; }

I’ve also written that if you want to add any behavior to this property, then you must create a variable and complete the code just as you would have a regular property. I was coding the other day and I had to transform add some behavior to what had been an automatic property. For grins, I wanted to see what I could get away with, so I tried a couple of different approaches.

First, I really only wanted to add behavior to the Setter, so I tried leaving the Getter as is:

// Will not compile
public string FirstName
{
    get;
    set
    {
        FirstName = value.TrimEnd(new char[] { ' ' });
    }
}

This will not compile, resulting in the following error:

‘ConsoleTestBed.Person.FirstName.get’ must declare a body because it is not marked abstract, extern, or partial

OK, so no joy there, I have to fill out the Getter. But notice in the Setter block there is no error! So I fill out the Getter and it looks like this:

// This compiles
public string FirstName
{
    get { return FirstName; }
    set
    {
        FirstName = value.TrimEnd(new char[] { ' ' });
    }
}

This compiles just fine. What I’m hoping at this point is that the Compiler will recognize what I am doing (given its context) and still create the variable for me. However, when I run it, I get a StackOverflowException. What you have probably figured out, and what I was afraid of, is that by referencing the Property name within the Property, I have created a recursion problem. So, unfortunately, I was originally correct: in order to make these changes work, I have to create a variable to support the Property:

// This compile AND works
private string _firstName;
public string FirstName
{
    get { return _firstName; }
    set
    {
        _firstName = value.TrimEnd(new char[] { ' ' });
    }
}

So if your program throws a StackOverflowException on a Property, be sure that you haven’t created a Recursion issue. Maybe someday the C# compiler guys can find a way to make this work based on the Context, or maybe a Property Attribute.

Advertisements
Categories: .NET 3.5, C# 3.0

Making Automatic Properties Read Only

November 28, 2007 Comments off

In yesterday’s post, I included a blurb about Automatic Properties. Today, in my weekly C# class at my company, I was showing Automatic Properties to my students and I mentioned that you could not have a Read Only automatic property. To prove this, I removed the Setter from like so:

// This will not compile
public string FirstName { get; }

I then received a Compile error indicating that an Automatic Property must have both a getter and a setter. I was about to say that this proved my point when it dawned on me that I could try making the setter private, like so:

// Look, a Read Only Automatic Property!
public string FirstName { get; private set; }

Now this compiles just fine. I swear that at VSLive I saw someone try this and it failed, so either my memory is faulty or this was corrected before VS2008 went RTM. In either case, you can now implement an Automatic Property with a private Setter.

In my book, this is not truly Read Only, since the value can still be changed internally, but at least external consumers of the Property will not be able to alter its value, so I’ll still consider this a way to have a Read Only Automatic Property.

Categories: .NET 3.5, C# 3.0

Visual Studio 2008 Class Diagram

November 29, 2007 12 comments

I’ll be returning to my series on “Upgrading your C# skills” next week. For now, though, I wanted to share with you a cool new option in VS2008: Class Diagrams.

Class Diagrams

A Class Diagram is a new file type that allows you to visually create, edit, and manage Classes, Structs, Enums, Interfaces, Delegates, and more. It is a quick and easy way to add Property and Method stubs to existing Classes or to create entire class shells. You can even manage Events and Fields. The interface is immediately familiar and intuitive. Diagrams can even be exported to Images.

To begin, open a project in Visual Studio and follow these steps:

  • In the Solution Explorer window, right click the project and select “Add -> New Item”.
  • From the Add New Item dialog box, highlight “Class Diagram” and give it a name.
  • Press the Add button. The Class Diagram file will be added to your project and the designer will open.

You will now have a Blank Diagram to work with in the designer. To add an existing class to the diagram, simply drag and drop it from the Solution Explorer window onto the design surface. To create a new Class (or Struct, Enum, etc.), right click in the designer and expand the “Add ->” menu item. Select the appropriate type and follow the instructions. Easy as pie.

Once you have an item in the designer, it will look something like this (Click on Screen Shot for Full Size):

Class Diagram Screenshot

I moved the Class Details window to the right, but the default will have it on the bottom. Just like working with a Control in a Form, you will need to select the class in the designer window in order for its details to show in the Class Detail window. And you can have multiple classes in a diagram.

When you create a new item, you will be prompted to either create a new file or append to an existing file. As you can see, the Class Detail window allows you to easily add Methods, Properties, Fields, and Events to a class. You can edit the Name of an element, the Type, the Access Modifier, and the Summary. The Summary column is the XML Comments description: if you leave it blank, then there will be no XML comments at all. If you supply a Summary, it will be added to the source code. You can also elect to “Hide” an element, which only means that it will be not listed in the Class Diagram itself.

So let’s talk about what code the IDE generates from this designer. Consider the Person class listed above: this class already existed and was dropped into the Class Diagram designer. I then added the DOB, MaritalStatus, and IsMilitaryVeteran properties using the Class Detail window. Now the code looks like this:

class Person
{
    public Person()
    {

    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    /// 
    /// Date Of Birth
    /// 
    public string DOB
    {
        get
        {
            throw new System.NotImplementedException();
        }
        set
        {
        }
    }

    /// 
    /// Marital Status Code
    /// 
    public char MaritalStatus
    {
        get
        {
            throw new System.NotImplementedException();
        }
        set
        {
        }
    }

    /// 
    /// Exposes whether or not this Person ever served in the Armed Forces
    /// 
    public bool IsMilitaryVeteran
    {
        get
        {
            throw new System.NotImplementedException();
        }
        set
        {
        }
    }
}

The properties were created, but not as I would have expected. I would have expected these to be default Automatic Property stubs. Instead, they are classic property stubs, and the getter throws a NotImplementedException. The good news is that this will compile as is. The bad news is that it is surely not the behavior you want, so you will have to do some work to implement the details. And you cannot simply remove the NotImplementedException because the getter must have a return path. Of course, a simple copy and paste can quickly convert these to Automatic Properties, but it is unfortunate that this isn’t the default behavior.

Which brings up another good point: the Property is created, but with no corresponding variable, and yet it still compiles. This tells me that the Automatic Property mechanism is still in play here, but it causes a problem when you go to implement the details: there is no variable to return, so you must create one. A pretty minor point, but worth noting none-the-less. And again, I think this issue could have been avoided if the standard Automatic Property stub had been implemented (or at least optional).

So let’s make this a little more robust and add some other goodies. First, since I have to implement the details anyway, I’m going to add fields to support my new properties. Next, I’m going to add a GetFullName method, and I’m going to override the ToString method. Finally, I’m going to add a MaritalStatusChangedEvent Event Handler. Now let’s look at the results:

class Person
{
    private string _dob;
    private bool _isMilitaryVeteran;
    private char _maritalStatus;

    public event EventHandler MaritalStatusChangedEvent;

    public Person()
    {

    }

    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    /// 
    /// Date Of Birth
    /// 
    public string DOB
    {
        get
        {
            throw new System.NotImplementedException();
        }
        set
        {
        }
    }

    /// 
    /// Marital Status Code
    /// 
    public char MaritalStatus
    {
        get
        {
            throw new System.NotImplementedException();
        }
        set
        {
        }
    }

    /// 
    /// Exposes whether or not this Person ever served in the Armed Forces
    /// 
    public bool IsMilitaryVeteran
    {
        get
        {
            throw new System.NotImplementedException();
        }
        set
        {
        }
    }

    /// 
    /// Retrieves the Full Name of the Person formatted as "Last, First".
    /// 
    public string GetFullName()
    {
        throw new System.NotImplementedException();
    }

    public string ToString()
    {
        throw new System.NotImplementedException();
    }
}

Much as expected, the fields are simple fields, the Event is declared, and the methods are stubbed but all throw a NotImplementedException. This all compiles right out of the box, but if you want to really override ToString(), you’ll need to add the keyword yourself. Again, it would be nice if the tool detected that for you and prompted you to select the desired behavior, but it is not that big of a deal.

Finally, the Class Diagram tool has some options. When you open one, VS2008 will include a new Menu and a new Toolbar. Explore these options a little and you’ll find some other helpful items. In this last screen shot, representing the completed class above, I have elected to show full signature detail in the Designer. (Click on Screen Shot for Full Size).

Class Diagram Screenshot

So I encourage you to explore this feature. For rapid stubbing, I think you’ll find this a very handy and useful tool.

Categories: Visual Studio

Upgrade your C# Skills part 2 – Compiler Inference, Object Initializers, and Anonymous Types

November 27, 2007 7 comments

Well, that Title sure is a mouthful! “Compiler Inference”, “Object Initializers”, “Anonymous Types”: as fancy as these items sound, they are among some of the more mundane changes to C# 3.0. Don’t get me wrong: these changes lay the groundwork for all the really cool stuff going on in C#, especially LINQ. Truthfully, I should have covered these first, but I had actually been dreaming about Extension Methods, so I hope you’ll understand if I had to get that out of my system!

Compiler Inference

It probably isn’t fair for me to say this is “mundane”, but look at the two examples below:

// Old Way
Person p = new Person();
string name = p.LastName + " " + p.FirstName;

// New Way
var p = new Person();
var name = p.LastName + " " + p.FirstName;

Doesn’t seem like much, does it? All we did was replace the explicit Type with a new keyword called var. When you see var, what you are seeing is an instruction to the compiler to figure out for itself what Type the resulting variable will be. This is NOT var like in PHP or other loosely typed languages. Once assigned by the compiler, all the Strongly Typed rules still apply. And var can only be used for local variables, so it won’t be replacing all type references any time soon.

In the example above, “var p = new Person();”, the compiler will infer from the return type that variable “p” should be of type “Person”. Granted, in this simple example it doesn’t really mean much. It does mean less typing, especially when looping through generic collections, but where it will really come into play is with Anonymous Types and LINQ. In fact, without Compiler Inference, Anonymous Types could not function, but more on that later in the article.

There is some debate going on as to when to use Compiler Inference. Some feel that using var whenever possible is just lazy and leads to less readable code. These people think that you should use it only when it is really needed. In other words, if I know p is going to be a Person, then why not say so explicitly? Personally, I don’t have an opinion. I’ll use it when it seems convenient and of course where it is required. It certainly makes looping through Collections nicer to write:

// assume people is a List<Person>
foreach (var person in people)
{
    Console.WriteLine("{0} {1} is {2} years old.", person.FirstName, person.LastName, person.Age);
}

I have to think that if Person is later subclassed, fewer changes would be required to make this code continue to function. Is it lazy? Perhaps, but we all know that a good programmer is a lazy thief!

Object Initializers

Another cool feature are Object Initializers. Initializers allow you to set a series of Property variables when you create the object. How many times have you coded something like this:

Person p = new Person();
p.FirstName = "John";
p.LastName = "Smith";
p.Age = 32;

Now, you can shorten this considerably. Sort of like Array Initializers, which I’m sure we’ve all used, the syntax is a list of property=value pairs inside curly braces immediately following a constructor:

// You could, of course, use var here...
Person p = new Person() {FirstName = "John", LastName = "Smith", Age = 32};

An interesting side note about IntelliSense: naturally, inside the initializer block, IntelliSense will show you the list of properties available for the Person object. As you use Properties in the Initializer block, you will notice that they disappear from IntelliSense. This is a quick way to make sure you set every property (if you need to), and should help prevent listing duplicate properties (which, incidentally, throws a compiler error).

Now, for some extra coolness, you can embed Object Initialization inside a Collection’s Object Initializing block, so that this:

List<person> people = new List<person>();
Person p = new Person();
p.FirstName = "John";
p.LastName = "Smith";
p.Age = 32;
people.Add(p);

Person p2 = new Person()
p2.FirstName = "Jimmy";
p2.LastName = "Crackcorn";
p2.Age = 57;
people.Add(p2);

Person p3 = new Person();
p3.FirstName = "Mary";
p3.LastName = "Contrary";
p3.Age = 44;
people.Add(p3);

Can now be done like this:

var people = new List<person>()
    {new Person() {FirstName = "John", LastName = "Smith", Age = 32},
     new Person() {FirstName = "Jimmy", LastName = "Crackcorn", Age = 57},
     new Person() {FirstName = "Mary", LastName = "Contrary", Age = 44}};

As you can see, this is very concise and readable code. Less Typing = More Cool!

Automatic Properties

Since we are talking about properties, at least in a round about way, I want to throw in a quick item you may not be aware of called Automatic Properties. We all know that we are supposed to be exposing access to our variables via properties, but a lot of the time all we want to do is to be able to read and write the variable data. As such, we end up with a lot of code that looks like this:

private string _firstName;
public string FirstName
{
    get { return _firstName; }
    set { _firstName = value; }
}

Now, there is nothing wrong with this approach, but it feels a little verbose. To address this, you can now use an Automatic Property:

public string FirstName { get; set; }

The two main differences are that you do not define the variable, and you do not have to write the getter and setter logic. In fact, you’ll notice there aren’t even curly braces for get or set. The upside is that it is again less code for a common function. The downside is that you do not have an internal variable to access: you must use the Property name, even internally. Also, the Property must contain both the get and the set, so you cannot have a read-only Automatic Property. You also cannot add custom logic: get and set default behaviors are it.

The plus, though, is that if you start with an Automatic Property and need to add any of this functionality, you simply create the variable and update the Property as you would have before. There is nothing magic about Automatic Properties, this is just another example of the Compiler doing menial work for you. One last tidbit: in VS2008, if you use the “prop” code snippet, you will get the format of an Automatic Property by default. It really replaces the need for my Property Builder tool.

Anonymous Types

When I first learned about Anonymous Types, I didn’t think it would be all that big of a deal. The more I think about it though, the more I can see a use for it. And when I saw how they are used with LINQ, I was sold. Basically, you can define a Type without naming it or creating a separate class definition. Let’s revisit our Person and People class from before, only this time I am not going to define the Person Class:

var p1 = new {FirstName = "John", LastName = "Smith", Age = 32, FirstName="Harold"};
var p2 = new {FirstName = "Jimmy", LastName = "Crackcorn", Age = 57};
var p3 = new {FirstName = "Mary", LastName = "Contrary", Age = 44};

Here I have created three instances of my new Type, but I have not explicitly defined the type definition. Instead, the compiler has created a class for me and given it the Properties I listed (using our new friend, Compiler Inference). All of the properties are read-only, so once created, the values cannot be changed. Since the three objects above are all identical in their property names, all three objects are of the same (unknown) type. And IntelliSense still works as well: Typing “p1.” will reveal a list of the properties. I said earlier in the article that Anonymous Types could not function without Compiler Inference: hopefully it is obvious now what is happening above. “var” is the only option here, because the Type of the variable does not exist at design time. The Compiler must infer the Type to be of whatever class the Compiler creates, otherwise, you could not have Anonymous Types in a language like C# because of its strong typing.

Of course, there is a catch: as of yet, I have not figured out a way to use these in a list. You cannot use a Generic list, because there is no Type for strong typing. You can store them as Objects, but then you cannot cast them back out because there is no type. So what does this particular method buy you? In my opinion, not much. There could be an argument for using this method to replace the use of temporary Structs, a method I use frequently to store grouped information. But since I can’t store them in a list or pass these objects around, it would be a very limited approach.

There is, however, a necessary use for Anonymous Types: LINQ requires them to be able to create custom query results as a Collection. We’ll explore that more later this week, so be sure to check back.

Categories: .NET 3.5, C# 3.0, Visual Studio

Live Blogging VSLive! Austin – Day 2

November 13, 2007 Comments off

Keynote Address “Mapping your way through Microsoft’s Managed Data Access” – Michael Pizzo, Microsoft

10:30am:

The purpose of LINQ is to overcome some of the inherent flaws in Ad Hoc SQL data access from applications.

  • LINQ provides a set of language extensions
  • Integrates Query access as part of the application rather than implemented as Strings
  • Return values are in fact classes complete with strong typing rather than generic DataSets
  • Implements IQueryable to use LINQ over Collections
  • LINQ is available against DataSets, XML, and Entities as well as SQL

LINQ to SQL:

This is going to be the most important part of LINQ. This will essentially allow integration of the SQL Schema into usable objects in the Application.

  • Essentially a Strongly Typed SqlClient
  • Classes map to tables, views, SQL, and other Schema
  • Classes are generated by the LINQ Designer in VS2008 (saw a great demo of this)
  • Allows simple renaming of properties
  • Foreign Keys are implemented as Relationships
  • This means that additional table rows can be read in using Object syntax as opposed to additional SQL
  • Allows Type Inheritance for sub-Schema relationships
  • Can perform better than IDataReader
  • Can use StoredProcedures instead of SQL
  • Uses DataContext objects instead of IDbConnection – be sure to wrap in using statements for proper disposal
  • SQL Results become objects
  • Foreign Keys are available as Collections
  • DataContext has a .Log property for retrieving connection information
  • DataLoadOptions class allows finer control over when and how Related tables are read into the object

LINQ to DataSet:

  • DataSets still have value
  • Disconnected, serializable, etc.
  • LINQ makes filters, joins, projections, cross DataTable and cross Collection queries
  • Supports Typed and Untyped DataSets

ADO.NET Entity Framework:

The Entity Framework allows the Database Schema to be translated into complex Business objects.

  • Object Models are more complex than Schema’s rectangular storage model
  • Enables apps to work with higher level concepts such as relational navigation
  • Supports Type inheritance
  • Built over DataProviders
  • EntityClient is a declarative mapping of model to schema
  • LINQ can run over EntityClient
  • Produces Business objects
  • Provides Change tracking
  • Designers for this built into VS2008

The Future – Astoria:

  • Data Services over the web
  • LINQ/Query/CRUD over the web
  • Delivered as XML
  • Consumed over HTTP
  • LINQ can be used in Silverlight

11:40am update:

Attended “LING: What’s it all about?” by Ken Getz. I was really afraid that after the excellent keynote it would be repetitive, but NOT SO! I got so much out of it, and lots of it is not LINQ specific.

  • LINQ format is From… Where… OrderBy… Select
  • Select is always last, which really throws us SQL users
  • Select is last in order to properly support Intellisense (which unfortunately really only works in VB for now)
  • The From clause includes an item handle and indicates a Data Source
  • Uses implicit variable declarations – in both VB and C#, you can get an object variable to define it’s own type based on return value

Extensions Methods:

  • Add new methods to existing classes without access to the source code
  • Must be Public
  • Must accept a parameter of the type you wish to extend
  • In C#, it must be defined in a Static Class
  • C# uses the this keyword to indicate that this is an extension method
  • Can be used as a Static Class Method or an Instance method

Automatic Properties:

  • For properties that only expose an internal variable, the need to define and use that variable is no longer required
  • Does not require Constructors to update them, but it opens the problem of initializing properties that are not included in any constructor
  • SO – a Constructor can be used that does not actually exist: properties can be indicated on the new statement like so: MyClass c = new MyClass() {prop1 = value, prop2 = value};
  • Which means you can use a Constructor that essentially does not exist

LINQ for Objects:

  • Great for analyzing Collections
  • Takes advantage of Extensions Methods
  • Query class has many built in extensions:Any, All, Average, Where, Concat, Contains, Convert, Count, Distinct, Except, etc. etc.
  • Can use functions in Select clause
  • Functions must supply an expression (called “Lambda Expressions”)
  • Can include Anonymous Methods
  • Expressions can only have one item in and one item out
  • There can only be one expression on a function
  • Example: foreach(Actor a in Actors.Where(x => x.BirthDate.Month == 9))
  • “x” above is the individual object notation, “=>” indicates execute this comparison
  • Can use Anonymous Types – essentially, these are objects created on the fly (like creating columns in SQL Select) and added as a new Type to the resulting objects in the resulting Collection
  • Example: “Select new {NameOfProperty = actor.LastName + “, ” + actor.FirstName}”
  • Use Skip and Take to paginate different rows from within a collection

1:40pm update:

Attended “Styles and Data Templates” given by Bill Hollis. A good follow on from where we left off yesterday, the class got into some of the finer aspects of Templates and Styles. The more I see this stuff, the more I want to smack my head: I’ve had 3.0 installed since last year’s conference, but I’ve never forced myself to spend some time learning any of it. I look at it now and wish I had. But in truth this is the right time to be learning about it: with VS2008 and Blend, the technology is finally beginning to catch up with the theory. This is also the right time for my company given that we are just entering the development stage of a new suite of Applications. But enough rambling, on to the highlights:

  • Styles can be changed on the fly for any Element using the FindResource() method
  • TargetType is used to specify a style for all Elements of the same type en masse (within subsequent scope). This can be applied at any level, where ever a Resource can be defined (which is anywhere)
  • TargetType can only be applied to a single Type (this is not true for named Styles) – it cannot be found and applied to children of a different type
  • You can develop and import ResourceDictionaries to store Resources externally – think reuse, like importing CSS files
  • Styles support inheritance, so you can pull from a common parent and apply additional styles or override styles for specific elements
  • Style precedence is deermined from the element up, so if the element describes and style, then it overrides any named styles or TargetTypes
  • Inheritance accomplished by using “BasedOn={StaticResource parentStyleName}” on the Style definition
  • Styles can be tied to properties (and Events in WPF have reflecting properties, so by extension they can be tied to Events also)
  • DataBinding can be done at the Control or Container level, so you can specify a single Binding for an entire DataTemplate or Panel and then use it in child Elements
  • DataTemplate is like a mini-Window defined in XAML
  • DataTemplate places content in a ContentControl
  • The root Element is usuallya Panel, but can be anything
  • Anything goes regarding layout with a DataTemplate
  • Blend has a DataTemplate editor (why doesn’t VS have some of this stuff?)
  • A DataTemplate can have Triggers that change aspects of its display based on events and properties
  • They can be applied base don individual properties to any level Element

I have not seen it demonstrated, but after the presentation Billy confirmed that he has seen Vista Gadgets built on WPF. Man, the possibilities here are unbelievable. WPF really is the first GUI paradigm shift we’ve since the GUI was created.

3:10pm update – VS2008 Overview:

  • VS is a shell that hosts other Components
  • Because 3.0 and 3.5 build on 2.0, there is distinct support for each of these three frameworks in VS2008
  • 2008 Solution files are a little different than 2005
  • ASP.NET Web Applicaiton projects have AJAX support built in
  • Intellisense can be hidden by holding the CTRL key down (well, not really hidden, but it becomes translucent)
  • Intellisense is expanded and improved in VS2008: supports LINQ
  • JavaScript Debugging – use F9 to set breakpoints
  • Complete access to the Document object tree in debug
  • There is an ImmediateWindow for making and testing on the fly Script changes
  • WCF support is built in to VS2008
  • WPF Designer is built in to VS2008 (but investigate Blend)
  • WPF anchoring is controlled inside the designer window, not the properties grid
  • ClickOnce support enhaned
  • VS2008 also has XSLT debugging
  • XSLT breakpoints can be set in both theXSLT and the Data Source file
  • Web Apps have a Split Screen designer option
  • Support has been added for nested Master Pages

4:20pm update:

Attended a class on “Expression Blend for Developers” by Billy Hollis. Not really a lot of new information, but it did go into more detail and show some more hands on type use of Blend.

  • Blend is part of the Expression Suite, but Blend is included in MSDN. The rest of the suite is really meant for Graphics Designers.
  • Blend is the preferred tool for developing WPF and SilverLight UI.
  • Blend and Visual Studio share the same projects, so when you create a project in Blend you must select the Framework and Language targets even though you cannot develop code in Blend.
  • Blend is designed for Wide Format screens, so that will grant a better user experience than traditional aspect ratios.
  • Blend will execute code written in VS.
  • Grid is the default root element of any new WPF app in Blend, but it can be changed to other Panel types.
  • Grid Columns are better designed in VS than in Blend: the properties grid in VS makes setting column and row information easier while Blend only allows you to approximate sizes by eye on the design surface.
  • Otherwise, Blend is the superior tool for the UI development.
  • XAML editing in Blend does not have Intellisense (but VS does)
  • Blend has visual tools for creating DataTemplates and Styles and can save them as Resources, either for the Application, Windows, or a ResourceDictionary
  • Blend can set up DataBinding using a drop and drag technique

After all I’ve seen, between WPF and Blend, C# 3.5 and LINQ, all I can say is that I am going to have a lot of fun over the next few months.

Post session update:

The last session of the day was on the new Entity Data Model.? The keynote this morning had already hit most of the highlights, but in this session we actually got to see some of the tools and results.? And again, I am very impressed.? The technology is not ready for prime time (which is fitting since it won’t be released until spring), but it has great promise.? The point of it all is to be able to further abstract the database schema from the objects that use it.? EDM is all about abstraction: data mapping rules stored in XML files are how the complexity is managed.

Basically, the objects are defined as you would actually use them, with no regard to how they relate to database schema.? The framework then generates “go between” code to handle CRUD operations.? LINQ is used heavily to interface with the resulting Entities.? This will definitely be a technology to watch.? Here are some final bullets:

  • Can be done in VS2008, but you need to load the ADO.NET Entity Framework and tools separately
  • Provides graphical modeling of databases and Entities
  • The resulting Entities are then used in lieu of the actual DB connection (using the ADO.NET disconnected model).? In other words, you treat data like objects
  • One Entity can update multiple tables seamlessly, and the schema relationships are maintained
  • If the schema changes, must rerun the wizard to regenerate the new Entities. (unless you are a masochist who likes to do things manually)

More to come tomorrow.? Whew, these days can really wear you out!

Categories: .NET 3.5, C# 3.0, LINQ, WPF