0

I'm trying to make something with repository pattern i made 3 layers winUI , dll and repository all of them has referenced entity framework but my base repository doesn't work here is code below

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using KuzeyYeli.ORM.Models;

namespace KuzeyYeli.Repository
{
    public class RepositoryBase<T> where T:class
    {

        private static NORTHWNDContext context;
        //singelton pattern
        public NORTHWNDContext Context
        {

            get {
                   if (context==null)
                          context=new NORTHWNDContext();
                   return context;
                }
            set { context = value;}
        }

        public IList<T> Listele()
        {
            return Context.Set<T>.ToList();
        }


    }
}

Set gives me error like " does not contain definition for 'set' and no extension " and by the way when i write "Context." i cant see the classes made by EF i really neeed to know please help

Piotr Olaszewski
  • 6,017
  • 5
  • 38
  • 65
  • Not positive it will fix you error, but you probably want to take the `static` off of your member variable. Marking it as static makes it global for all instances that inherit from your base class, and it will persist across all requests. Not what you want. – Sam Aug 01 '15 at 03:52
  • i know but thats the poin of singleton pattern it suppose to show me classes inside NORTHWNDContext (which is my database classes) right after i write "Context." in Listele method – Lokman Tasbas Aug 01 '15 at 03:57
  • 1
    It may be the point of a singleton pattern, but a singleton pattern has no business in the repository pattern – Aydin Aug 01 '15 at 03:59
  • You might want to review the answers to this question: http://stackoverflow.com/questions/31646525/net-managing-layers-relationships/31659634#31659634 – Tyree Jackson Aug 01 '15 at 04:52

1 Answers1

3

The whole point of having a repository pattern is to decouple the various layers in your application in addition to making it easier to unit test your application.

The proper way to implement the repository pattern is to have an interface that defines four basic methods...

public interface IEntity
{
    string Id { get; set; } 
}

public interface IRepository<T> where T : IEntity
{
    void Add(T entity);
    void Remove(T entity);
    void Create(T entity);
    T Find(string id);
}

Now you can implement this interface for any of your entities, let's imagine you're creating a blog, a blog would contain posts right?

So, create a PostsRepository...

public class Post : IEntity
{
    public Post()
    {
        this.Id = Guid.NewGuid().ToString();
    }

    public string Id { get; set;}
}

public class PostsRepository : IRepository<Post>
{
    public void Add(Post entity);
    /// etc
}

That's how it's supposed to be implemented, though the above example does not take into consideration that the data access logic is composed using Entity Framework.


Now that we know what the Repository Pattern is, let's move on to integrating Entity Framework...

In the PostsRepository class, you would have a property that could reference your Entity Framework DbContext. Remember that PostsRepository is a concrete implementation which will be used for any other class that is dependent on IRepository.


So why bother, seems like a lot of trouble for little gain, but you'd be wrong...

Imagine that you're attempting to validate content within a post that is submitted to a website... How would isolate the validation logic whilst avoiding making any calls to the database?

You could either create hand rolled mock objects that implement IRepository that doesn't reference EntityFramework as the data source (this is a long winded approach)... or you could simply use frameworks available out there already such as Moq, which you use to create a fake implementation of IRepository.


So, in short what you need to start studying is:

  • Dependency Inversion
  • Repository Pattern
  • Decorator Pattern
  • N-Tier architecture
  • Onion architecture

All of those will have a major impact on how maintainable your application will be once the code base has grown. You don't need to be an expert, that will come through making mistakes and biting a few bullets here and there... but having a general understanding of those will make tremendous difference even in the short term.

Aydin
  • 15,016
  • 4
  • 32
  • 42
  • thanks so much sir , its really helping topic for myself new learner of Ef and repository pattern and i found my mistake where i did wrong its about visual studio i gues when i refferenced my ORM layer to repository layer it made a NOORTHWNDContext.cs but when i checked it was "empty" when i coppied the ORM layer's context to Repository layer it fixed i m just saying if anyone still thinking whats wrong just saying it is fixed.. – Lokman Tasbas Aug 01 '15 at 04:41
  • Your welcome, remember the best way to learn is by doing! all these subjects sound overwhelming because they're new terms... once you realise how simple the concept behind each pattern is, and what purpose they serve, it all becomes a breeze, – Aydin Aug 01 '15 at 05:57
  • 1
    Also have a look at using a Unit Of Work pattern to further abstract your context. In this case Entity Framework. – DDiVita Aug 01 '15 at 13:33