I don’t think you should. The Entity Framework is already an abstraction layer over your database. The context uses the unit of work pattern and each DBSet is a repository. Adding a Repository pattern on top of this distances you from the features of your ORM. I talked about this in my blog post: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern … Read more
Edit: Original answer used Find instead of Local.SingleOrDefault. It worked in combination with @Juan’s Save method but it could cause unnecessary queries to database and else part was probably never executed (executing the else part would cause exception because Find already queried the database and hadn’t found the entity so it could not be updated). … Read more
This Git project is very helpful. I started from the same and did some changes as per my need. public sealed class DalSession : IDisposable { public DalSession() { _connection = new OleDbConnection(DalCommon.ConnectionString); _connection.Open(); _unitOfWork = new UnitOfWork(_connection); } IDbConnection _connection = null; UnitOfWork _unitOfWork = null; public UnitOfWork UnitOfWork { get { return _unitOfWork; … Read more
Just think of it this way, the domain model should be dependent upon nothing and have no infrastructure code within it. The domain model should not be serializable or inherit from some ORM objects or even share them. These are all infrastructure concerns and should be defined separate from the domain model. But, that is … Read more
Thank you everyone, but problem was in my AppRepositoryProvider. As it’s binding exception, then obviously the problem was with binding 🙂 Correct file is: <?php namespace App\Providers; use Illuminate\Support\ServiceProvider; class AppRepositoryProvider extends ServiceProvider { public function boot() {} public function register() { $models = array( ‘CustomModel’, ‘CustomModel2’, ‘CustomModel3’ ); foreach ($models as $model) { $this->app->bind(“App\Contracts\\{$model}Interface”, … Read more
Use just the Include extension on IQueryable. It is available in EF 4.1 assembly. If you don’t want to reference that assembly in your upper layers create wrapper extension method in your data access assembly. Here you have example: public static IQueryable<T> IncludeMultiple<T>(this IQueryable<T> query, params Expression<Func<T, object>>[] includes) where T : class { if … Read more
You can read my “repository for dummies” post to understand the simple principle of the repository. I think your problem is that you’re working with DTOs and in that scenario, you don’t really use the repository pattern, you’re using a DAO. The main difference between a repository and a dao is that a repository returns … Read more
One thing that i did wrong when played around with repository pattern – just like you, i thought that table relates to repository 1:1. When we apply some rules from Domain Driven Design – grouping repositories problem often disappears. Repository should be per Aggregate root and not table. It means – if entity shouldn’t live … Read more
Reason: By design, LINQ to Entities requires the whole LINQ query expression to be translated to a server query. Only a few uncorrelated subexpressions (expressions in the query that do not depend on the results from the server) are evaluated on the client before the query is translated. Arbitrary method invocations that do not have … Read more
Disclaimer: Since there aren’t any great answers yet, I decided to post a part from a great blog post I read a while ago, copied almost verbatim. You can find the full blog post here. So here it is: We can define the following two interfaces: public interface IQuery<TResult> { } public interface IQueryHandler<TQuery, TResult> … Read more