Question

Linq to SQL creates objects which are IQueryable and full of relations.
Html Helpers require specific interface objects like IEnumerable<SelectListItem>.

What I think could happen:

• Reuse the objects from Linq to SQL without all the baggage, i.e., return Pocos from the Linq to SQL objects without additional Domain Model classes?
• Extract objects that easily convert to (or are) Html helper objects like the SelectListItem enumeration?

Is there any way to do this without breaking separation of concerns? Some neat oop trick to bridge the needs?

For example, if this were within a repository, the SelectListItem wouldn’t be there. The select new is a nice way to cut out an object from the Linq to SQL without the baggage but it’s still referencing a class that shouldn’t be referenced:

 IEnumerable<SelectListItem> result = (from record in db.table
                                       select new SelectListItem {
                                           Selected = record.selected,
                                           Text= record.Text, 
                                           Value= record.Value }
                                      ).AsEnumerable();

Answer 1

I have seen the user of an IService interface and Service class. Basically it’s the step between the repository and the controller.

Pros:

• Allows for methods that manipulate the return values of IRepository actions
• Good separation of concerns
• Can be the bridge where the validation logic lives before the repository is involved.
• Can work with Dependency injection frameworks/patterns

Cons:

• Mucho duplication of code. Unless you expose the repository, you will probably be duplicating almost all of your IRepository methods in the IService
• Can become a “catch-all” class. The god class that does everything! Muahahaha… etc

I’m sure there are more, but that’s something I’ve seen and used.