I'm "upgrading" an MVC app. Previously, the DAL was a part of the Model, as a series of repositories (based on the entity name) using standard LINQ to SQL queries. Now, it's a separate project and is generated using PLINQO.
Since PLINQO generates query extensions based on the properties of the entity, I started using them directly in my controller... and eliminated the repositories all together.
It's working fine, this is more a question to draw upon your experience, should I continue down this path or should I rebuild the repositories (using PLINQO as the DAL within the repository files)?
One benefit of just using the PLINQO generated data context is that when I need DB access, I just make one reference to the the data context. Under the repository pattern, I had to reference each repository when I needed data access, sometimes needing to reference multiple repositories on a single controller.
The big benefit I saw on the repositories, were aptly named query methods (i.e. FindAllProductsByCategoryId(int id), etc...). With the PLINQO code, it's _db.Product.ByCatId(int id) - which isn't too bad either.
I like both, but where it gets "harrier" is when the query uses predicates. I can roll that up into the repository query method. But on the PLINQO code, it would be something like _db.Product.Where(x => x.CatId == 1 && x.OrderId == 1); I'm not so sure I like having code like that in my controllers.
Whats your take on this?
-- QUERY EXTENSIONS --
PLINQO's Query Extensions are designed to be chainable. This is supposed to help keep things from getting too "harry". ;)
_db.Product.Where(x => x.CatId == 1 && x.OrderId == 1);
// Query Extensions
// Even more complicated Lambda
_db.Product.Where(x => (x.CatId == 1 || x.CatId == 3) && x.OrderId != 1);
// Query Extensions
_db.Product.ByCatId(1, 3).ByOrderId(ComparisonOperator.NotEqual, 1);
Also, for really complex queries we suggest adding custom extension methods to the editable (passively generated) query extension files. This allows you to encapsulate your more advanced logic into a single place and keep your code cleaner and advanced logic more reusable.
-- PATTERN --
As for pattern, we generally suggest that you new up a DataContext in a using statement every time you want to access the DB. LINQ to SQL (and thus PLINQO) are using the Unit of Work pattern, and are designed to work well in small controlled scopes.