I am going to give another blog posting after this one on the old school .edmx approach to Entity Framework which, in contrast to the slick, new code first stuff, tightly binds all data back to a marginally more spiffy version of LINQ to SQL or something very much like it. I am helping a friend (Bhavani Akole) with code and in doing so I caught dinner with another friend (Femi Oyekan) tonight who showed me a thing or two about old school EF. Before I can show you any of that, I need to show you how a dummy database I set up is set up. First, I made a database called "Repo" and I put two tables in it. The first table is called "Ying." (Please forgive all the bad names which are to follow.)
Ying is seen above. I made YingId the primary key by making it a uniqueidentifer type, clicking that little key icon to put the key icon at the row for YingId, and also setting the default value to newid() so that when I manually populate rows that I might not have to manually add at Guid into the YingId column. (Instead when I leave the row a Guid will be placed in the cell for me, though my UI for MSSQL Server Management Studio Express 2012 was sluggish to show it.) I then made a Yang table and gave it some columns. I set a YangId as a comparable primary key. It also made another uniqueidentifier type column called YingId. After I had saved off the table, I revisited it in "Design" and right clicked to pick "Relationships..." so that I might tie YingId in Yang to YingId in Ying!
I got a dialog box which looked like this, where I clicked "Add" and then I clicked the button with the three dots by "Tables And Columns Spec."
I then got a second dialog box where I made the association from one YingId to another like so:
I then put some corny data in my two corny tables!
Again, thanks to Olufemi Oyekan for his help tonight.
I promise there is a follow up blog posting coming after this one.
No comments:
Post a Comment