Entity Framework Architecture
Hi All,
I'm looking for some best practices and lessons learned real world experience. This is more of a high-level programming architecture for how our programming patterns are going to be laid out.
The one thing I'm sure of is that I want everything to go thru our classes. I don't want multiple definitions of the same code on multiple pages where we're trying to find out everywhere we need to update them. The page (we're currently still using webforms) calls the class, the class calls EF, and all custom logic is done inside the class.
The issues we're coming across are when dealing with joins, anonymous types, and the like. Our developers are worried about select all columns every time for all queries as we've seen that can hamper performance. If we do dynamic types then we lose intellisense and open ourselves up to runtime errors.
We've seen a bunch of other sites recommend using custom classes for each result set, but I can picture that getting messy with the amount of tables / joins / applications we have that cross reference each other.
We can return IQuerables, select the columns with intellisense, but then we're limited to a single object and aren't sure if that'll work if we need to update the data we're retrieving.
So I'm asking the community what patterns they use and what they wish they knew when designing the way they were going to use EF from the ground up. Any and all help greatly appreciated.
I'm looking for some best practices and lessons learned real world experience. This is more of a high-level programming architecture for how our programming patterns are going to be laid out.
The one thing I'm sure of is that I want everything to go thru our classes. I don't want multiple definitions of the same code on multiple pages where we're trying to find out everywhere we need to update them. The page (we're currently still using webforms) calls the class, the class calls EF, and all custom logic is done inside the class.
The issues we're coming across are when dealing with joins, anonymous types, and the like. Our developers are worried about select all columns every time for all queries as we've seen that can hamper performance. If we do dynamic types then we lose intellisense and open ourselves up to runtime errors.
We've seen a bunch of other sites recommend using custom classes for each result set, but I can picture that getting messy with the amount of tables / joins / applications we have that cross reference each other.
We can return IQuerables, select the columns with intellisense, but then we're limited to a single object and aren't sure if that'll work if we need to update the data we're retrieving.
So I'm asking the community what patterns they use and what they wish they knew when designing the way they were going to use EF from the ground up. Any and all help greatly appreciated.
ASKER
Hi Megan,
Yeah, we're looking at taking a similar approach. Our current plan is to have the classes return an iqueriable . . . which gives anything that uses the classes the ability to setup the query the way they want and then pull the data. We're also looking at using computed columns (delegateDecompiler) to provide extended properties where needed.
Are you doing any joins in your classes or how do you handle combining multiple tables? (Or do you just foreign key it and enumerate over the list given by EF)?
Just trying to do that planning now so we don't run into issues later. Any samples you can provide or gotchyas you've come across would be greatly appreciated.
Thanks in advanced.
-Kyle
Yeah, we're looking at taking a similar approach. Our current plan is to have the classes return an iqueriable . . . which gives anything that uses the classes the ability to setup the query the way they want and then pull the data. We're also looking at using computed columns (delegateDecompiler) to provide extended properties where needed.
Are you doing any joins in your classes or how do you handle combining multiple tables? (Or do you just foreign key it and enumerate over the list given by EF)?
Just trying to do that planning now so we don't run into issues later. Any samples you can provide or gotchyas you've come across would be greatly appreciated.
Thanks in advanced.
-Kyle
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
That approach makes sense. I haven't personally used it, so unfortunately I'm not able to offer any helpful insight concerning things to look out for, etc.
ASKER
Pattern we went with. Thanks for the help.
This sounds like a View Model approach, and you're concern about it getting "messy" is exactly why I've avoided that pattern. My approach has been a compromise between strict MVC and MVVC. Rather than create a View Model for every View, I create methods / classes in my Models that serve a more generic purpose (so they can be re-used), and use LINQ to retrieve the columns I need. This takes some planning up front, and flexibility in the development process in order to adjust for new or un-anticipated requirements.
So, it's similar to a View Model approach, but I avoid creating custom classes for every result set.