Return to Answer

You are looking for the Repository pattern, which abstracts a collection of domain objects. A repository for your domain might look like:

public interface IAccountRepository { IList<Account> GetAll(); Account GetById(int accountId); // Insert and delete, if they apply // Other account-specific queries and operations } 

A presenter would declare a dependency on an IAccountRepository:

public class EditAccountPresenter { private readonly IEditAccountView _view; private readonly IAccountRepository _accounts; public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) { _view = view; _accounts = accounts; _view.Initializing += OnInitializing; } private void OnInitializing(object sender, EventArgs e) { _view.BindAccount(_accounts.GetById(234)); } } 

Next, implement IAccountRepository however you like and put it all together when you create the presenter:

var dataContext = new AccountDataContext("...connection string..."); this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

This helps to decouple the definition of the operations from their actual implementation. It also allows you to choose which repository you give the presenter, decoupling it from the implementation as well.

The flexibility of this approach offers more freedom, and stands up better to change, than directly instantiating dependencies. This is called the Dependency Injection pattern.

You are looking for the Repository pattern, which abstracts a collection of domain objects. A repository for your domain might look like:

public interface IAccountRepository { IList<Account> GetAll(); Account GetById(int accountId); // Insert and delete, if they apply // Other account-specific queries and operations } 

A presenter would declare a dependency on an IAccountRepository:

public class EditAccountPresenter { private readonly IEditAccountView _view; private readonly IAccountRepository _accounts; public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) { _view = view; _accounts = accounts; _view.DataBinding += OnDataBinding; } private void OnDataBinding(object sender, EventArgs e) { _view.Account = _accounts.GetById(234); } } 

Next, implement IAccountRepository however you like and put it all together when you create the presenter:

var dataContext = new AccountDataContext("...connection string..."); this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

This helps to decouple the definition of the operations from their actual implementation. It also allows you to choose which repository you give the presenter, decoupling it from the implementation as well.

The flexibility of this approach offers more freedom, and stands up better to change, than directly instantiating dependencies. This is called the Dependency Injection pattern.

You are looking for the Repository pattern, which abstracts a collection of domain objects. A repository for your domain might look like:

public interface IAccountRepository { IList<Account> GetAll(); Account GetById(int accountId); // Insert and delete, if they apply // Other account-specific queries and operations } 

A presenter would declare a dependency on an IAccountRepository:

public class EditAccountPresenter { private readonly IEditAccountView _view; private readonly IAccountRepository _accounts; public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) { _view = view; _accounts = accounts; _view.Initializing += OnInitializing; } private void OnInitializing(object sender, EventArgs e) { _view.BindAccount(_accounts.GetById(234)); } } 

Next, implement IAccountRepository however you like and put it all together when you create the presenter:

var dataContext = new AccountDataContext("...connection string..."); this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

This helps to decouple the definition of the operations from their actual implementation. It also allows you to choose which repository you give the presenter, decoupling it from the actual implementation as well.

The flexibility of this approach offers more freedom, and stands up better to change, than directly instantiating dependencies. This is called the Dependency Injection pattern.

You are looking for the Repository pattern, which abstracts a collection of domain objects. A repository for your domain might look like:

public interface IAccountRepository { IList<Account> GetAll(); Account GetById(int accountId); // Insert and delete, if they apply // Other account-specific queries and operations } 

A presenter would declare a dependency on an IAccountRepository:

public class EditAccountPresenter { private readonly IEditAccountView _view; private readonly IAccountRepository _accounts; public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) { _view = view; _accounts = accounts; _view.Initializing += OnInitializing; } private void OnInitializing(object sender, EventArgs e) { _view.BindAccount(_accounts.GetById(234)); } } 

Next, implement IAccountRepository however you like and put it all together when you create the presenter:

var dataContext = new AccountDataContext("...connection string..."); this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

This helps to decouple the definition of the operations from their actual implementation. It also allows you to choose which repository you give the presenter, decoupling it from the implementation as well.

The flexibility of this approach offers more freedom, and stands up better to change, than directly instantiating dependencies. This is called the Dependency Injection pattern.

You are looking for the Repository pattern, which abstracts a collection of domain objects. A repository for your domain might look like:

public interface IAccountRepository { IList<Account> GetAll(); Account GetById(int accountId); // Insert and delete, if they apply // Other account-specific queries and operations } 

A presenter would declare a dependency on an IAccountRepository:

public class EditAccountPresenter { private readonly IEditAccountView _view; private readonly IAccountRepository _accounts; public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) { _view = view; _accounts = accounts; _view.Initializing += OnInitializing; } private void OnInitializing(object sender, EventArgs e) { _view.BindAccount(_accounts.GetById(234)); } } 

Next, implement IAccountRepository however you like. This helps to decouple the definition of the operations from their actual implementation.

Finally, put it all together when you create the presenter:

var dataContext = new AccountDataContext("...connection string..."); this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

You are looking for the Repository pattern, which abstracts a collection of domain objects. A repository for your domain might look like:

public interface IAccountRepository { IList<Account> GetAll(); Account GetById(int accountId); // Insert and delete, if they apply // Other account-specific queries and operations } 

A presenter would declare a dependency on an IAccountRepository:

public class EditAccountPresenter { private readonly IEditAccountView _view; private readonly IAccountRepository _accounts; public EditAccountPresenter(IEditAccountView view, IAccountRepository accounts) { _view = view; _accounts = accounts; _view.Initializing += OnInitializing; } private void OnInitializing(object sender, EventArgs e) { _view.BindAccount(_accounts.GetById(234)); } } 

Next, implement IAccountRepository however you like and put it all together when you create the presenter:

var dataContext = new AccountDataContext("...connection string..."); this.Presenter = new EditAccountPresenter(this, new AccountRepository(dataContext)); 

This helps to decouple the definition of the operations from their actual implementation. It also allows you to choose which repository you give the presenter, decoupling it from the actual implementation as well.

The flexibility of this approach offers more freedom, and stands up better to change, than directly instantiating dependencies. This is called the Dependency Injection pattern.