Inside of a Visual Studio solution when project A has some code that reaches into a repository in project B and the method therein has some acrobatics which end up requiring a type from project A even though project B doesn't have the type (in my case I am mapping from a POCO made from consuming Excel sheet gunk and then mapping getsetters from the POCO onto getsetters at an Entity Framework object while casting some string getsetters to getsetters of other types) well the problem may be hacked around by handing in a method from project A to project B as a Func or as an Action. There is a bit of a readability problem with what I have going on stemming from an inability to use ref or out variables. I want to hand in an Entity Framework object and get it back, doctored-up, and then save changes on the context. Well, I shouldn't just get a new variable back from a Func and then attach the new variable to the context in advance of a save as that would be adding something that was already there as the pointer/reference for the object is never broken as it goes into the Func and then back out the other side and even if it was via a deep clone or something the originally object would still be in the context and you still wouldn't want a readd. Since the pointer/reference never breaks. I could get a variable back from the Func, do nothing with it, and then save the context. Well, that is ghetto too. I have settled for handing in the object at the mouth of the method and not returning it at all. Even if an Action returns void a reference type inside of its machinery can get affected and in the next line of code after the call to the Action the object will have the battle scars from the meat grinder it just went through. Not all that readable.
No comments:
Post a Comment