views:

63

answers:

1

Referring to this question, let's say we have the following scenario -

A model class User that implements IUser

[MetadataType(typeof(IUser))]
public class User : IUser

And a repository that handles saving, retrieving etc. of this from whichever datastore we want to use

public class UserRepository : IRepository<User>
IQueryable<User> GetAUserBySomeCriteriaOrOther(int aParam, string anotherParam);

Further on we would have a controller and perhaps a view on top as well, each expecting an instance of IQueryable<User>.

My questions is thus: What are the advantages/disadvantages of passing the results back from the repository as (say) an IQueryable<User> compared to an IQueryable<IUser> ?

My reason for asking is that most examples/demos I see would use IQueryable<User>, but this seems to me to be introducing a coupling between higher layers and whichever method I use to generate the User class. Say I want to change from Linq-to-Sql to Entity Framework - is that not then a big headache?

A: 

EntityFramework does not support querying over interfaces. Linq2Sql can figure it out ok.

Generally your User class will look the same between all .NET ORMs. Your linq and model classes will probably not change when you switch ORMS.

jfar
Sorry to labour the point a bit but to be clear:In the example, I would have a class User, which would be passed back from whatever repository/ORM I used?So I could start with Linq2SQL, get a month down the line, and decide actually let's change to NHibernate and so long as the NHibernate repository returned the same User class, the layers above would carry on happily?
glosrob
Most likely. The shape/definition of your User wouldn't change and therefore all calling code wouldn't care. I have a demo/scratchpad project I constantly switch ORMs for and its pretty easy to do.
jfar