Design question: mvc 3 and the data layer
-
Hi all. I'm working through the architecture for an ASP.NET MVC 3 solution. I like using LINQ and will probably use the entity framework against a SQL database as the persistence repository. I've seen a lot of examples now where a controller will send lambda expressions to the repository object as a way of indicating a filter, rather than having a specific function declared in the repository interface for the filter scenario. This seems convenient, and performs well as long as you have a LINQ-to-entities or LINQ-toSql compliant repository. I started down that path, but I'm now concerned that it doesn't separate the concerns as much as it should. In the event a new repository layer was needed, one would need to build/implement something that can work with the lambda expressions (e.g construct SQL from the expression tree, or otherwise implementing IQueryable). Otherwise the use of LINQ would require loading a full set into memory from the datastore, potentially killing performance. My question is this: is this a valid concern? Or is the support for LINQ-enabled repositories strong enough among enough database systems that the convenience of LINQ outweighs the coupling concern?