views:

247

answers:

1

Model #1 - This model sits in a database on our Dev Server. Model #1

Model #2 - This model sits in a database on our Prod Server and is updated each day by automatic feeds. alt text

I have written what should be some simple code to sync my feed (Model #2) into my working DB (Model #1). Please note this is prototype code and the models may not be as pretty as they should. Also, the entry into Model #1 for the feed link data (mainly ClientID) is a manual process at this point which is why I am writing this simple sync method.

private void SyncFeeds()
{
    var sourceList = from a in _dbFeed.Auto where a.Active == true select a;
    foreach (RivWorks.Model.NegotiationAutos.Auto source in sourceList)
    {
        var targetList = from a in _dbRiv.Product where a.alternateProductID == source.AutoID select a;
        if (targetList.Count() > 0)
        {
            // UPDATE...
            try
            {
                var product = targetList.First();
                product.alternateProductID = source.AutoID;
                product.isFromFeed = true;
                product.isDeleted = false;
                product.SKU = source.StockNumber;
                _dbRiv.SaveChanges();
            }
            catch (Exception ex)
            {
                string m = ex.Message;
            }
        }
        else
        {
            // INSERT...
            try
            {
                long clientID = source.Client.ClientID;
                var companyDetail = (from a in _dbRiv.AutoNegotiationDetails where a.ClientID == clientID select a).First();
                var company = companyDetail.Company;
                switch (companyDetail.FeedSourceTable.ToUpper())
                {
                    case "AUTO":
                        var product = new RivWorks.Model.Negotiation.Product();
                        product.alternateProductID = source.AutoID;
                        product.isFromFeed = true;
                        product.isDeleted = false;
                        product.SKU = source.StockNumber;
                        company.Product.Add(product);
                        break;
                }
                _dbRiv.SaveChanges();
            }
            catch (Exception ex)
            {
                string m = ex.Message;
            }
        }
    }
}

Now for the questions:

  1. In Model #2, the class structure for Auto is missing ClientID (see red circled area). Now, everything I have learned, EF creates a child class of Client and I should be able to find the ClientID in the child class. Yet, when I run my code, source.Client is a NULL object. Am I expecting something that EF does not do? Is there a way to populate the child class correctly?
  2. Why does EF hide the child entity ID (ClientID in this case) in the parent table? Is there any way to expose it?
  3. What else sticks out like the proverbial sore thumb?

TIA

+2  A: 

1) The reason you are seeing a null for source.Client is because related objects are not loaded until you request them, or they are otherwise loaded into the object context. The following will load them explicitly:

if (!source.ClientReference.IsLoaded)
{
    source.ClientReference.Load();
}

However, this is sub-optimal when you have a list of more than one record, as it sends one database query per Load() call. A better alternative is to the Include() method in your initial query, to instruct the ORM to load the related entities you are interested in, so:

var sourceList = from a in _dbFeed.Auto .Include("Client") where a.Active == true select a;

An alternative third method is to use something call relationship fix-up, where if, in your example for instance, the related clients had been queried previously, they would still be in your object context. For example:

var clients = (from a in _dbFeed.Client select a).ToList();

The EF will then 'fix-up' the relationships so source.Client would not be null. Obviously this is only something you would do if you required a list of all clients for synching, so is not relevant for your specific example.

Always remember that objects are never loaded into the EF unless you request them!

2) The first version of the EF deliberately does not map foreign key fields to observable fields or properties. This is a good rundown on the matter. In EF4.0, I understand foreign keys will be exposed due to popular demand.

3) One issue you may run into is the number of database queries requesting Products or AutoNegotiationContacts may generate. As an alternative, consider loading them in bulk or with a join on your initial query.

It's also seen as good practice to use an object context for one 'operation', then dispose of it, rather than persisting them across requests. There is very little overhead in initialising one, so one object context per SychFeeds() is more appropriate. ObjectContext implements IDisposable, so you can instantiate it in a using block and wrap the method's contents in that, to ensure everything is cleaned up correctly once your changes are submitted.

Joe Lloyd
Thanks for the feedback. So much to remember and so many good practices to cement into place. So far, I like EF much better than ADO.NET - though there is a learning curve cost involved. But - I **love** learning!!
Keith Barrows
On another note: The context is created at the entry point for this whole class. The class is instantiated, a single method is called then the class is nulled as it is part of a Web Service with no session state. I am looking at how to use the using clause in this situation. I declare my context in the declarations area of the class. Each web service method instantiates this class, calls a method, then nulls out the class on exit from the method. (Make sense?)
Keith Barrows
If the whole purpose of the class is for one method, you could just wrap the method content in the using statement, e.g.private void SynchFeed(){ using (YourContext _dbRiv = new YourContext()) { // do work }}This assumes, as I think you've stated, that the context (or class) does nothing apart from SynchFeed(). I'm not that familiar with using web services, so if this isn't viable, my apologies.In this case it's not a big deal - it's when you keep contexts alive across multiple operations, i.e. many calls to SyncFeed(), that you should really consider refactoring.
Joe Lloyd
Got it. Thanks.The Class has several public methods like GetProductById(id), GetProductByCompany(id), SaveProduct(product), DeleteProduct(id), etc. In each of the Get methods I call the Private Sync() method once then do the Get action. So, the call sequence would look like: 3rd Party Web Page --> Our Web Service (WS) --> Instantiate ProductManager (PM) object (context is created) --> Execute a Get, Save or Delete --> If Get, run Sync --> PM returns result to WS --> WS drops PM (end of context) --> WS returns --> web site consumes data package. Repeat cycle for each WS call.
Keith Barrows