Thus, when we looked at the impedance mismatch both
of applications and of data services, we realized that for
the data-services case, you don’t want objects with methods and behaviors. What you want is a value-based, richer
structural data model.
By value-based, I mean the ability to have high-level
constructs such as entities and relationships but without
the behaviors. Just as the relational model is a value-based model, we felt that we needed to provide a layer of
abstraction that is richer in terms of entities and relationships. Therefore, the Entity Data Model and the Entity
Framework became a natural layer of abstraction that we
felt had to be built, and it’s at that level of abstraction
where the mapping between richer-level entities and
semantic concepts such as inheritance is abstracted.
Now the Entity Data Model, which is the formalism
that defines the Entity Framework value-based layer, is
very close to the object data model of .NET, modulo the
behaviors. We decided to let the Entity Framework take
care of all the mapping concerns and then just build thin
programming-language veneers, or wrappers, over entities
to expose a variety of programming-language bindings
over this infrastructure. You can have a binding over C#,
Visual Basic, or XML—you pick the programming model
that you want.
EM I would like to point out that there’s a deep analogy
with how I explained LINQ in the beginning. We’re trying to abstract not one particular case where you go from
tables to objects, but rather a wide variety of different
things for different uses. So instead of having a one-off
thing, we’re trying to generalize this concept so that there
are many other situations in which it’s applicable.
TC There has been a lot of press in the developer com-
munity about functional languages—how they are up and
coming and how they are going to help us do multicore.
My perspective is that something like LINQ is almost a
hybrid system because it’s bringing elements of functional programming directly into the imperative programming environment that most of us are operating in.
I’m curious, do you see it that way, and how do you see
EM Yes, definitely. There is a very clear link to functional
programming. For example, if you really want to get
geeky, LINQ is just another way of doing what is known
in Haskell as monads. So it’s really taking concepts from
functional programming and bringing them into object-oriented languages.
The functional programming aspects are also visible if
you look at the way these LINQ operators—the standard
query operators—are defined. They all take functions
as their argument. If you have a WHERE operator, for
example, it takes a predicate to check whether to filter
out something. What is a predicate? Well, that’s a function from some value to a Boolean. The way you parse
that predicate is by a lambda expression, and, again, that
comes directly from functional programming.
Another aspect to consider is tuples, or anonymous
types. Of course, they are used in SQL for rows, but a lot
of functional programming languages also have tuples,
and again we use them when we’re doing projections.
Type inference is another example where functional
programming concepts come in. It has been in languages
such as ML and Haskell for at least 30 years, and we have
now moved it into C# and Visual Basic.
Speaking of many-core programming, there’s a project
called P-LINQ, which is an implementation of LINQ to
run over many-core. Again, you describe all these things
in a more declarative way using functions that you pass
around, which allows the compiler to take this query and
manipulate it, optimize it, and run it in parallel.
In a sense it’s similar to what SQL Server does when
it takes the query and runs it in parallel. But now we’ve
moved that to the realm of the programming language.
So, yes, there is definitely a mixture or infusion of functional programming and object-oriented programming.
I would like to stress that functional programming
and object-oriented programming are more similar than
most people realize. A lambda expression or a delegate is
really a special class that has one method called invoke
or apply, or something similar. Because it’s a class that
has only one method, you can add syntactic sugar such
that you don’t have to mention the apply method but
you can supply the arguments directly to the delegate,