Home / My Disclaimer / Who am I? / Search... / Sign in

// Architects

What Makes us Want to Program? Part 1

by Steve Syfuhs / January 02, 2009 04:00 PM

When I saw this comic a couple weeks ago, it hit a chord just right with me.

Except of course it was PHP, and grade 9.  The funny thing was, I started writing programs way back when I was in grade 5.  I tried to start learning development when I was in grade 3.  Let me tell you, there are certain subtleties to programming that don’t quite become apparent to a 9 year old.

10 PRINT “Steve is Awesome!”
20 GOTO 10

While QBasic was fun to play with, I gave up on that when I found a book on Visual Basic in Grade 5.  I vaguely remember it being Visual Basic 5 too.  I could be wrong.  It was a little more than 10 years ago – you do the math.  The problem I found with VB was that it didn’t feel all that intuitive from a language perspective to me.  I could never find it to flow properly.  But at the time, that’s all I had to go on.  So I gave up on development for a while and tried my hand at HTML.  Once again, certain things just aren’t apparent at certain ages.  When I first tried HTML, I started in notepad.  Shortly thereafter I ended in notepad.  Maybe sports would be more fun?  Nah… Enter FrontPage a few months later.

After finally getting the hang of FrontPage, I built some amazing (read: ugly) sites.  All-in-all they weren’t bad for an 11 year old.

Once middle school rolled around, I tried my hand at the other sciences and found out I really enjoyed biology.  Being the semi-OCD-like person I am, I put all my attention into biology and medicine, with a curiosity for chemistry.  I knew way too much for my own good.

Now I have to mention that all of this is taking place in beautiful Southern California.  I was born and raised there for 14 years.  At the end of Grade 8, my parents decided to move to Canada.  Don’t ask - long story.  And at that time, I was still into the life sciences.  In my next post, I’ll continue on with my story.

ADO.NET Entity Framework and SQL Server 2008

by Steve Syfuhs / December 29, 2008 04:00 PM
Do you remember the SubSonic project? The Entity Framework is kind of like that. You can create an extensible and customizable data model from any type of source. It takes the boiler plate coding away from developing Data Access Layers.

Entity is designed to seperate how data is stored and how data is used. It's called an Object-Relational Mapping framework. You point the framework at the source, tell it what kind of business objects you want, and poof: you have an object model. Entity is also designed to play nicely with LINQ. You can use it as a data source when querying with LINQ. In my previous post, the query used NorthwindModEntities as a data source. It is an Entity object.

Entity Framework
Courtesy of Wikipedia

The Architecture, as defined in the picture:

  • Data source specific providers, which abstracts the ADO.NET interfaces to connect to the database when programming against the conceptual schema.
  • Map provider, a database-specific provider that translates the Entity SQL command tree into a query in the native SQL flavor of the database. It includes the Store specific bridge, which is the component that is responsible for translating the generic command tree into a store-specific command tree.
  • EDM parser and view mapping, which takes the SDL specification of the data model and how it maps onto the underlying relational model and enables programming against the conceptual model. From the relational schema, it creates views of the data corresponding to the conceptual model. It aggregates information from multiple tables in order to aggregate them into an entity, and splits an update to an entity into multiple updates to whichever table contributed to that entity.
  • Query and update pipeline, processes queries, filters and update-requests to convert them into canonical command trees which are then converted into store-specific queries by the map provider.
  • Metadata services, which handle all metadata related to entities, relationships and mappings.
  • Transactions, to integrate with transactional capabilities of the underlying store. If the underlying store does not support transactions, support for it needs to be implemented at this layer.
  • Conceptual layer API, the runtime that exposes the programming model for coding against the conceptual schema. It follows the ADO.NET pattern of using Connection objects to refer to the map provider, using Command objects to send the query, and returning EntityResultSets or EntitySets containing the result.
  • Disconnected components, which locally caches datasets and entity sets for using the ADO.NET Entity Framework in an occasionally connected environment.
    • Embedded database: ADO.NET Entity Framework includes a lightweight embedded database for client-side caching and querying of relational data.
  • Design tools, such as Mapping Designer are also included with ADO.NET Entity Framework which simplifies the job on mapping a conceptual schema to the relational schema and specifying which properties of an entity type correspond to which table in the database.
  • Programming layers, which exposes the EDM as programming constructs which can be consumed by programming languages.
  • Object services, automatically generate code for CLR classes that expose the same properties as an entity, thus enabling instantiation of entities as .NET objects.
  • Web services, which expose entities as web services.
  • High level services, such as reporting services which work on entities rather than relational data.

// About

Steve is a renaissance kid when it comes to technology. He spends his time in the security stack.