I've seen a few answers that get in the general area of this question, but none that directly gets at what I'm seeing. I've inherited a recent code base with a charter to make the code run faster. It looks to me like each of the tables in the database (one database) is given its own dbcontext. These tables are highly relational and the major issue I keep seeing is that decisions need to be made based on foreign key relationships between tables. With this design approach, every time two tables are involved, the developer nested using statements for each context (good on him for auto cleanup, right), grabs the data from table A, then, loops through table B row by row to find matches (usually we're interested in the non-matches so that we can just update table B), then proceed. I have certainly seen multiple contexts used in an app, but I've never seen this "pattern" and cannot figure out why one would use it. Before I rewrite this part of the app so that each table is in the same context, I felt I should do a sanity/reality check to make sure that there isn't some really bad monster waiting for me. Obviously, I cannot find anything. Here's a pseudo snippet (exact code with table and column name changes):
var beers = from b in beerContext.AllBeersOffered
where b.CurrentStock = 1
select b;
foreach(var beer in beers)
{
Bars bars = barContext.AllBeersCarried.FirstOrDefault(x=>x.BeerId==beer.Id)
if(bars == null)
{
//Create a List of beers offered but not carried in that bar,
// which is then added to another table.
}
}
Again, my inclination is very much Whiskey-Tango-Foxtrot, move the tables to one DbContext and handle this in one insert, but that requires assuming a deeper level of really, really bad coding than I'm comfortable making. Obviously, the original programmer is long gone from the business and we think the profession entirely. But, he apparently was a pretty experienced developer (Java, though), so I don't like to assume incompetence when it could be something I'm missing. My question is, could you justify this design, and if so, what should I look for?
Aucun commentaire:
Enregistrer un commentaire