Include Foreign Fields

Using Entity Framework, , when I want to include an additional field, say CompanyName from the Customers table in the Invoices collection, I create a Partial Invoice class with CompanyName as an extra field, but can I populate that field with an ExecuteStoreQuery(selct Invoices.*, Cusotmers.CompanyName from Invoices Inner Join Customers...)?
Or do I have to pull off two collections Customers/Invoices and run a Linq join on them?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bob LearnedCommented:
That question doesn't make any sense...
Silas2Author Commented:
Actually, I've cheated by making generic wrapper that populates the EF objects from SQL string when your edmx tables don't match your EF classes you've  extended with partial classes, I can't see any real disadvantage apart from going out of the pattern and not using _context.GetObjects.
I wonder who uses EF out-of-the-box and has any hair left...
Bob LearnedCommented:
I don't use it.  I am not sure how you "cheated"...
Exploring ASP.NET Core: Fundamentals

Learn to build web apps and services, IoT apps, and mobile backends by covering the fundamentals of ASP.NET Core and  exploring the core foundations for app libraries.

Silas2Author Commented:
The cheat is I'm using my own wrapper to populate List<MyClasses> rather than the EF which is supposed to have the same functionality, it just seems to be restrictive in how it does it, and crippling in its performance overhead.
Bob LearnedCommented:
Auto-generated classes, or POCO?  What does your wrapper look like?  What benefit are you getting from the Entity Framework?  Have you look at other ORM solutions?
Silas2Author Commented:
I've started with Auto-generated classes then realised they were so fat they wouldn't get over the WCF, so I'm busily replacing them with POCO 'Lite' versions, so using EF to pull the fat(obese) ones out of the db, then using refelection to populate a POCO one, then back to an EF one for persistance.
Its crazy, I've ended up writing my own ORM(again), which is lets face it 2 days work max. Why M'soft has made such a meal of it is beyond me.
And I agree, I'm getting nothing out of EF.
Bob LearnedCommented:
Have you evaluated NHibernate with Fluent Interface?
Silas2Author Commented:
Yes, I was using Fluent NHibernate for a small project, and it was a bit more 'realistic' but let me ask you a 'be honest' question, to write a CRUD wrapper round something like ADO.Net commands, specially with reflection so easy these days, filling/persisting/deleting Lists<ofPOCOClasses> is a pretty trivial operation, I'm starting to think it easier just to DIY, as you're always going to get version issues/implementation problems/WhysItDoingThat questions with a black box aren't you?
Bob LearnedCommented:
To be frank, that sounds like "garage programmer" speak.  The usual phrase is, "I can do it better then everyone else".  It just takes a commitment to learn as much about a system as possible, and work through solutions to any strange quirkiness.  There are a lot of frameworks, like NHibernate, that some really good developers have put a considerable amount of thought and optimization into, that I usually try not to summarily discount.  I have discovered, after careful consideration, that the Entity Framework wouldn't work for me, and I chose to go in a different direction.  There is no "golden hammer", though, that can fit all situations (and actual anti-pattern BTW).  You have to evaluate each situation and whether any tool is a good fit for that situation.

On the surface, reflection sounds like a trivial operation, but if you have to concern yourself with optimized coding, it is a very heavy operation, and should be used carefully.  
Silas2Author Commented:
Ok, give me sme real advantages of NHiberante of writing a simple CRUD wrapper? (there are a lot of disadvantes, not least that you get a lot of 'seapage' of NHiberate-specific code in you BOL, and how easy is that going to be over coming decades to maintian?). But my question is in earnest, what real advantage is there is these ORMs over a DIY one?
Bob LearnedCommented:
In my opinion, there is no "best practice".  What is good for me, may not be good for you.  If you resist ORMs, and have done a thorough assessment, then it is not the best choice for your situation.  

I tried to start a list of advantages and disadvantages:

NHibernate Advantages and Disadvantages
Silas2Author Commented:
Thank you for showing me that, and I'm not trying to be an awkward knob (although probably achievng it!) but when I look at the 'pro' list, there isn't one which woudnt equally (and some) apply to writing a reflection wrapper around a low-level (swithcable with fashion) data-access technology like ado.whatevecomesnext.
Your pont about reflection being a big overhead, if you really were going to populate massive result sets, which shouldn't really ever be necessary anyway, you can easily cache the reflection info.
+ SQL Server client does manage its own connection pooling anyway, what else is there?
Bob LearnedCommented:
Let's say that I prefer something that takes away the need to reinvent the wheel, if you will.  ORM systems handle the persistence mapping for me, and I don't have to concern myself with creating a hand-crafted system, that may or may not be as performant as an existing ORM system.  It is good for me to leverage such technology as interceptors, caching, etc., without having to know how to develop those myself.  I wouldn't have to troubleshoot and do performance monitoring for my own code.  I know that I have something in my toolbox that has been thoroughly tested, and there is a wealth of smarter people than me out there supporting it.

I will always go back to this concept:  not any single system can equally apply to all situations.

     "NHibernate may not be the best solution for data-centric applications that only use stored-procedures to implement the business logic in the database".  

NHibernate - Relational Persistence for Idiomatic .NET

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.