none
Using ObjectContext in WPF with decoupled custom entities RRS feed

  • Question

  • I am trying to use a pattern similar to what you see here http://sandbox.vbcity.com/blogs/vbfeeds/archive/2009/05/08/using-the-wpf-observablecollection-with-ef-entities.aspx where ObservableCollection is used with EF entities to handle the CRUD functions in a WPF application. But in my case I'm adding a custom entity to the mix and I'm not sure if it will work.

    Assume a poorly organized legacy DB that is locked and beyond your control. To make it simple let's say we have a user and salary table like this:

    CREATE TABLE [dbo].[tbl_users](
    	[userid] [int] NOT NULL,
    	[lastname] [nvarchar](50) NOT NULL,
    	[firstname] [nvarchar](50) NOT NULL,
     CONSTRAINT [PK_tbl_users] PRIMARY KEY CLUSTERED 
    (
    	[userid] ASC
    )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
    ) ON [PRIMARY]
    
    CREATE TABLE [dbo].[tbl_salary](
    	[userid] [int] NOT NULL,
    	[salary] [int] NOT NULL,
     CONSTRAINT [PK_tbl_salary] PRIMARY KEY CLUSTERED 
    (
    	[userid] ASC
    )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
    ) ON [PRIMARY]
    
    

    EF will generate entities tbl_users and tbl_salary but a more logical entity would be something like employee which might look like this:

    Public Class Employee
       Public Property empId as int
       Public Property lastname as string
       Public Property firstname as string
       Public Property salary as salary
    End Class
    
    

    The WPF client would bind to the employee entity which would decouple the app from the very poorly designed DB. Then if a change to the DB were made our client would be safe from changes.

    Creating a DAL to load from the EF entities to this custom entity isn't an issue, nor is binding the WPF client to the custom employee entity. The problem is having the add, update, and deletes propagated back to the DB using the EF. If I just use the entities tbl_users or tbl_salary then I get propagation via the EF by the ObjectContext as outlined in the link. But with my logical employee entity added on top, I am not sure how to keep that link back to the EF.

    The crux of the issue is the poor design of the DB. If I'm going to use the EF and LINQ to get around the inability to create stored procedures then I'd also like have the entities really represent something logical that makes sense to the app and can last the lifetime of the app. It seems like there is a gap that can't be bridged without extensive work.

    In this scenario, would it be wiser to just use the entities like tbl_users and tbl_salary and if a DB change did happen you totally rewrite your DAL (and probably a good portion of the client) to finally make the data more logical?


    After doing some research, I wonder if perhaps instead of a custom class defined outside the model, I should be looking to update the EF diagram with custom entities (http://msdn.microsoft.com/en-us/library/cc716779.aspx). However I don't like making updates the EF diagram because I am not 100% convinced it is something you want to do on a production application in it's current state.
    • Edited by pretzelb Wednesday, October 5, 2011 3:10 PM
    Wednesday, October 5, 2011 12:53 PM

Answers

  • Hi pretzelb,

    Thanks for your feedback.

    You can use Entity Spliting instead of a custom class defined outside the model. Actually the mapping scenarios in your link are supported good in EF, I think you may have a try.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by pretzelb Monday, October 10, 2011 2:09 PM
    Thursday, October 6, 2011 7:46 AM
    Moderator
  • Entity splitting might be an option. I do not like the idea of editing the model in the designer because I do not feel like the current version is functional enough to be used primarily (which is why I tried to create my classes outside the designer).

    I also found Scott Guthrie's old blog here (http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx) that outlines a Code First approach with an existing DB where the POCO classes are defined to be more logical than based on the existing schema. The end of the blog even goes to show how an address entity can be created from the "dinner" table even though "dinner" is also a separately defined object. This might work for me.

    I'm not sure if this is the best approach so I'm open to more suggestions, else I might mark this complete in a day or so.

    Thursday, October 6, 2011 7:55 PM

All replies

  • Hi pretzelb,

    Thanks for your feedback.

    You can use Entity Spliting instead of a custom class defined outside the model. Actually the mapping scenarios in your link are supported good in EF, I think you may have a try.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by pretzelb Monday, October 10, 2011 2:09 PM
    Thursday, October 6, 2011 7:46 AM
    Moderator
  • Entity splitting might be an option. I do not like the idea of editing the model in the designer because I do not feel like the current version is functional enough to be used primarily (which is why I tried to create my classes outside the designer).

    I also found Scott Guthrie's old blog here (http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx) that outlines a Code First approach with an existing DB where the POCO classes are defined to be more logical than based on the existing schema. The end of the blog even goes to show how an address entity can be created from the "dinner" table even though "dinner" is also a separately defined object. This might work for me.

    I'm not sure if this is the best approach so I'm open to more suggestions, else I might mark this complete in a day or so.

    Thursday, October 6, 2011 7:55 PM