EF и репозиторий

Question

Я пишу проект в MVC и использую EF 4.0.Я использую шаблон репозитория, но не уверен, где разместить некоторые свойства.

public interface IUserRepository<User> 
{
    User GetUserById(int userId);
    void UpdateUser(User user);
    void AddUser(User user);
    List<User> GetUsersByName(string userName);             
    void Create(User user);      
    int NumberOfFollowers { get; set; }     
}

Мои две проблемы: 1).должно ли свойство NumberOfFollowers быть свойством или методом?и 2).должен ли он быть размещен внутри класса сущности User вместо интерфейса?

cheers.

Answer 1

Если NumberOfFollowers является свойством пользователя, оно обязательно должно быть в классе User, а не в хранилище.Репозиторий отвечает за получение / размещение данных только .

Вот моя любимая реализация репозитория для EF:

http://www.codeproject.com/KB/database/ImplRepositoryPatternEF.aspx

ЭтоПотрясающе, очень полно и поставляется с большим количеством функций.

Answer 2

re: свойство или метод, .NET Design Guideless диктуют, что оно не должно быть свойством, если оно может a) выдавать исключение или b) возвращать заметное количество времени.

Answer 3

NumberOfFollowers будет собственностью самого пользователя, а не в интерфейсе репозитория.

Answer 4

Я написал блог об этом и рассказал о том, как абстрагировать специфические функции поставщика ORM, управление контекстом объекта для каждого запроса, управление моделями из нескольких баз данных, Управление транзакциями с помощью шаблона единицы работы с полным исходным кодом и примерами.,

Пожалуйста, посмотрите и дайте мне знать, если у вас есть какие-либо вопросы.

Answer 5

Я согласен с ответом Даниэля - было бы логично иметь свойство с именем NumberOfFollowers.Для справки: если есть данные, к которым вы можете получить доступ через сам объект User, создайте свойства \ методы непосредственно в классе User.Если у вас есть ключи foregin для других таблиц, то доступ к этим элементам данных может осуществляться через класс User и должен быть заключен в свойствах \ методов.

С другой стороны, если вы хотите найти информациюотносящиеся к User, но для этого потребуется помощь другого объекта, затем создайте класс UserService.Сделайте хранилище простым - используйте только методы извлечения данных / манипуляции и создавайте более сложные / требовательные к бизнес-логике методы в отдельном классе обслуживания, например

public class UserService {
    private DbContext Context {get; set;}

    public IList<Document> GetUserDocument(User user)
    {
        // Assuming User table does not have a Document ID as a foregin key..
        // Do whatever you need to do to get document.
    } }

Вышеприведенное описание является приблизительным и ни в коем случае не стандартом де-фактоно у меня это хорошо работает.