locked
Repository Architecture Using WebForm in C# With N Tier Architechure RRS feed

  • Question

  • User-1129594362 posted

    Hi can any one

    How can we create Repository Architecture Using WebForm in C#

    Step By Step Please

     

    Wednesday, May 30, 2012 5:38 AM

Answers

  • User750226543 posted

    To really leverage the Repository pattern fully, I recommend that this type of code be pushed down a layer to the busniess logic / domain layer and have the Repository Interface injected (DI) into the class via constructor (or Property). Then allow calling .Save(); on the domain class that uses the injected Interface as opposed to needing to know about the concrete class implementation of the repository. This then sets you up to be able to use any type of repository implementation as mentioned in the last thread: EF, raw ADO.NET, Enterprise Library, etc.

    ...also allows for testing, since you could pass in a mock of the IRepo, and test against this instead of actually hitting a db.

    Check of 'The Art of Unit Testing', and it will show you these concepts, in a short, easy to follow book. (http://artofunittesting.com/)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, June 20, 2012 10:26 AM

All replies

  • User1314433698 posted

    I assume you're really talking about the repository pattern and I assume you understand what the pattern is all about. Here're some basic steps to develop you code based on this pattern:

    1. Define a common interface for your repository classes:

    public interface IBookRepository
    {
        Book GetByIsbn(string isbn);
        IEnumerable<Book> GetByName(string name);
        void Add(Book b);
    }

    2. Define your repository class implementing the interface:

    public class BookRepository : IBookRepository
    {
        private NorthwindContext _context;
    
        public BookRepository()
        {
            _context = new NorthwindContext();
        }
    
        public Book GetByIsbn(string isbn)
        {
            return _context.Books.Single(c => c.Isbn == isbn);
        }
    
        public IEnumerable<Book> GetByName(string name)
        {
            return _context.Books.Where(c => c.Name.StartsWith(name)).AsEnumerable<Book>();
        }
    
        public void Add(Book b)
        {
            _context.Books.AddObject(b);
        }
    }

    3. Then use it in your client code (web form):

    BookRepository repository = new BookRepository();
    Book b = new Book( ... );
    repository.Add(b);
    context.SaveChanges();

    Note that I'm assuming you'd use EF as your ORM for all the entities; in this example, Book. Also, you should be able to make the interface generic enough for every entity, instead of Book-specific.

    HTH.

    Thursday, June 14, 2012 6:18 PM
  • User750226543 posted

    Note that I'm assuming you'd use EF as your ORM for all the entities; in this example, Book. Also, you should be able to make the interface generic enough for every entity, instead of Book-specific.

    The point of using an interface allows the implementer to chose whatever they like as the implementation....whether it's EF, Linq2SQL, ADO.NET, inline SQL (hopefully not) etc. 

    Also, to make the repo generic, the type Book should be replaced with T.

    Monday, June 18, 2012 4:41 AM
  • User-952121411 posted

    3. Then use it in your client code (web form):

    BookRepository repository = new BookRepository();
    Book b = new Book( ... );
    repository.Add(b);
    context.SaveChanges();

    To really leverage the Repository pattern fully, I recommend that this type of code be pushed down a layer to the busniess logic / domain layer and have the Repository Interface injected (DI) into the class via constructor (or Property). Then allow calling .Save(); on the domain class that uses the injected Interface as opposed to needing to know about the concrete class implementation of the repository. This then sets you up to be able to use any type of repository implementation as mentioned in the last thread: EF, raw ADO.NET, Enterprise Library, etc.

    Wednesday, June 20, 2012 9:42 AM
  • User750226543 posted

    To really leverage the Repository pattern fully, I recommend that this type of code be pushed down a layer to the busniess logic / domain layer and have the Repository Interface injected (DI) into the class via constructor (or Property). Then allow calling .Save(); on the domain class that uses the injected Interface as opposed to needing to know about the concrete class implementation of the repository. This then sets you up to be able to use any type of repository implementation as mentioned in the last thread: EF, raw ADO.NET, Enterprise Library, etc.

    ...also allows for testing, since you could pass in a mock of the IRepo, and test against this instead of actually hitting a db.

    Check of 'The Art of Unit Testing', and it will show you these concepts, in a short, easy to follow book. (http://artofunittesting.com/)

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, June 20, 2012 10:26 AM
  • User-1311657157 posted

    To really leverage the Repository pattern fully, I recommend that this type of code be pushed down a layer to the busniess logic / domain layer and have the Repository Interface injected (DI) into the class via constructor (or Property).

    I like this!  What would the client call look like (from the presentation layer)??

    Wednesday, June 20, 2012 11:30 AM
  • User750226543 posted

    The constructor of your class that needs the repo would look like:

    private IRepo myRepository;

    public myClass(IRepo repo)
    {
      myRepository = repo;
    }

    public void save(obj myObject)
    {
      myRepository.Save(myObject);
    }

    this is hand typed, but you should get the idea. Your class is now dependant on the interface, so you can supply the implementation via the constructor or look at a container such as Ninject, Spring, Unity etc

    http://haacked.com/archive/2007/12/07/tdd-and-dependency-injection-with-asp.net-mvc.aspx

    Wednesday, June 20, 2012 11:37 AM