Last post Dec 27, 2011 10:47 PM by Yorrick vd Voort
Dec 19, 2011 04:29 AM|Angad Bhat|LINK
I have created a repository per table in my data layer and injecting them in the service layer. All is working fine. Now, for a peice of functionality I need to communicate with 15 tables and so created 15 repositories. Using Ioc, I am injecting all 15 repositories
in my service layer. Is it good to inject so many repositories into the service layer?
Dec 20, 2011 01:12 AM|codeplanner|LINK
Dec 24, 2011 06:00 PM|Angad Bhat|LINK
I am using a Base repository. We have a base (generic) and specific repositories as well. I am injecting these repositories in a WCF service. The service works with about 12 tables for which I've created repostorries including base repository. Now, I don't
like the idea of injecting 12 in a service. Is there a good way of reducing the number of repositories I am injecting. E.g. a repository wrapping all the calls of lets say 6 other related repositories ...
Dec 25, 2011 04:00 AM|codeplanner|LINK
Do you really have the need for accessing all 12 repositories in one service?
Dec 26, 2011 10:03 PM|atconway|LINK
I have created a repository per table in my data layer
Is it good to inject so many repositories into the service layer?
I think that these (2) comments should be looked at separately. 1st when using IoC in the manner you have briefly described then,
yes it is proper to inject those repositories into the Service Layer. No issue there.
However the idea of 1 Repository per table might need to be rethought if possible. The idea behind the Repository Interfaces is that programming to the abstraction provides freedom for multiple implementations under the covers (without really understanding
or knowing about the actual persistence implementation), but if you are so closely modeling the Interfaces to these tables I wonder what benefit you are gaining. Also the Repositories Interfaces I write are typically about the methods to get the data
rather than he data itself. That's why a base Interface with the: Add, Save, Get, GetAll, Find, FindBy, etc. cover so much ground. Any additional specific methods can be created in Interfaces that Inherit from the base Interface and can expand on as needed.
Lastly, the idea of the object model in code is that is does not necessarily need to reflect the database schema 1:1 and often does not for the very issue you are encountering. If a person table has been normalized into 5 different tables but in
code only makes since as a single class, then modeling either the Entity or Repository to reflect this might save a lot of unneeded code.
Dec 27, 2011 10:47 PM|Yorrick vd Voort|LINK
When looking at twelve repositories in a service layer you could ask yourself the following questions:
Both questions, I think, are intertwined.
Regarding the first question, I think orchestrating the 12 repositories should be done in the Business Logic Layer (BLL) and the data collected from these repositories
should be consolidated into one model/return type. To me the service is just a mechanism to pass through some information not to hold the logic to know where to get all twelve different pieces of information and consolidate it.
When the above is the case and this is in the BLL, question two can be positively answered. It would be possible to reuse the BLL without recoding the logic of accessing
the repositories. I.e. the business logic layer you have created can be used by a web site, a Sliverlight application, a WPF application or as in your case by a WCF service. Just reference the DLL of the BLL project and inject the entity you need.
Loosely coupled is an important part of creating a flexible application but so is Separation of Concerns (SoC). I don’t think one can go without the other.
So to give you a short answer to your question:”
Is it good to inject so many repositories into the service layer?”
I don’t think so. But that’s just my opinion. :-)
Hope this helps.