0

I have an ASP.NET MVC3 application.

In my application I have the following EF classes (hasCauses and isOfProblems are navigation properties):

Problem {string ProblemId, string ProblemName, string ProblemDesc, bool solved, hasCauses}
Cause {string CauseId, string CauseName, string CauseDesc, isOfProblems}
ProblemCause {string ProblemId, string CauseId}

My Repository methods just return EF objects (same method for cause)

IQueryable<Problem> GetProblemsById(string problemId)

Now in my Service layer I have to create an object SolvedProblems that has to contain, among other fields, ProblemId and CauseId and of course they have to be related(according to ProblemCause). From my Service Layer I cannot "see" ProblemCause table because I do not use the navigation properties (they are used just in Repository). Therefore, I can create a method:

IQueryable<Cause> GetProblemsByCauseId(string causeId)

And fill the ProblemCause while iterating through the Problems. However, if instead of two tables (+ association) I have 3 or more tables interconnected? Is it worth to make this nested cycles or to bring all the logic to the Repository (where can I use navigation properties) and return SolvedProblems to the Service?

CiccioMiami
  • 8,028
  • 32
  • 90
  • 151

1 Answers1

0

If these are just simple joins, I think the easiest way to tackle this would be to create a view in your database and map SolvedProblems to it in EF.

Steve Danner
  • 21,818
  • 7
  • 41
  • 51
  • Thanks! A good alternative might be to create a SolvedProblems class within the EF namespace, that basically contains the DB View? Of course this class is populated by a method in the repository that perofrm the joins at application level – CiccioMiami Mar 15 '12 at 10:51