ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / EF Нужно ли изолировать и тестировать класс репозитория.
25 сообщений из 48, страница 1 из 2
  1  все
EF Нужно ли изолировать и тестировать класс репозитория.
    #37958820
Kane_sql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kane_sql
Гость
Возник вопрос, зачастую везде в примерах на mvc приводится возможность тестирования контроллера, однако не видел чтобы кто-то тестировал репозиторий.
К примеру я сгенерил контроллер, репозиторий и view с помощью скаффолдинга, получился вот такой код
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
public class ArticlesRepository : IArticlesRepository
    {
        ArticlesDbEntities context = new ArticlesDbEntities();

        public IQueryable<Articles> All
        {
            get { return context.Articles; }
        }

        public IQueryable<Articles> AllIncluding(params Expression<Func<Articles, object>>[] includeProperties)
        {
            IQueryable<Articles> query = context.Articles;
            foreach (var includeProperty in includeProperties) {
                query = query.Include(includeProperty);
            }
            return query;
        }

        public Articles Find(long id)
        {
            return context.Articles.Single(x => x.ArticleID == id);
        }

        public void InsertOrUpdate(Articles articles)
        {
            if (articles.ArticleID == default(long)) {
                // New entity
                context.Articles.AddObject(articles);
            } else {
                // Existing entity
                context.Articles.Attach(articles);
                context.ObjectStateManager.ChangeObjectState(articles, EntityState.Modified);
            }
        }

        public void Delete(long id)
        {
            var articles = context.Articles.Single(x => x.ArticleID == id);
            context.Articles.DeleteObject(articles);
        }

        public void Save()
        {
            context.SaveChanges();
        }

        public void Dispose() 
        {
            context.Dispose();
        }
    }

    public interface IArticlesRepository : IDisposable
    {
        IQueryable<Articles> All { get; }
        IQueryable<Articles> AllIncluding(params Expression<Func<Articles, object>>[] includeProperties);
        Articles Find(long id);
        void InsertOrUpdate(Articles articles);
        void Delete(long id);
        void Save();
    }




Однако в данном случае присутствует жесткая ссылка на ArticlesDbEntities, имхо лучше было бы для изоляции класса действовать через интерфейс IArticlesDbEntities. Но при таком подходе придется править автогенерируемый класс edmx контекста и реализовывать достаточно большие фейковые классы от IArticlesDbEntities. В общем стоит ли тестировать репозиторий?

ps. не исключено, что в репозиторий в дальнейшем будут добавляться другие методы.
...
Рейтинг: 0 / 0
15.09.2012, 13:52
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959040
Фотография a_titeev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_titeev
Участник
Kane_sql,

Зачем заниматься ерундой. сделайте дженерик и забудьте... а то не хватало тестами потом тестами обвешивать каждый.
...
Рейтинг: 0 / 0
15.09.2012, 23:57
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959042
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Энтити и так генерит репозиторий (контекст). На кой ляд писать обертку над оберткой?
...
Рейтинг: 0 / 0
16.09.2012, 00:00
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959046
Фотография a_titeev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_titeev
Участник
МСУЭнтити и так генерит репозиторий (конетекст). На кой ляд писать обертку над оберткой? ну не знаю... я например unitofwork пользую. очень удобно в него выносить отдельные репо, чем потом вспоминать где что и как
...
Рейтинг: 0 / 0
16.09.2012, 00:06
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959058
Kane_sql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kane_sql
Гость
a_titeevKane_sql,

Зачем заниматься ерундой. сделайте дженерик и забудьте... а то не хватало тестами потом тестами обвешивать каждый.

Дженерик то сделал, только вот у дженерика жесткая зависимость от ObjectContext:

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
 public abstract class BaseRepository<T> : IBaseRepository<T> where T : class 
    {
        private ObjectContext db;

        public BaseRepository() : this(new ArticlesDbEntities())
        { }

        public BaseRepository(ObjectContext context) 
        {
            this.db = context;
        }

        public void Create(T item)
        {
            db.CreateObjectSet<T>().AddObject(item);
        }

        public void Update(T item)
        {
            db.CreateObjectSet<T>().ApplyCurrentValues(item);
        }

        public IQueryable<T> GetAll()
        {
            return db.CreateObjectSet<T>();
        }

        public T GetItem(Expression<Func<T,bool>> predicate)
        {
            return db.CreateObjectSet<T>().SingleOrDefault(predicate);
        }

        public void Delete(Expression<Func<T, bool>> predicate) 
        {
            var item = this.GetItem(predicate);
            db.CreateObjectSet<T>().DeleteObject(item);
        }

        public void Dispose()
        {
            db.Dispose();
        }

        public void Save() 
        {
            db.SaveChanges();
        }

    }

    public interface IBaseRepository<T> : IDisposable where T : class
    {
        void Create(T item);
        System.Linq.IQueryable<T> GetAll();
        T GetItem(System.Linq.Expressions.Expression<Func<T, bool>> predicate);
        void Delete(System.Linq.Expressions.Expression<Func<T, bool>> predicate);
        void Update(T item);
        void Save();
    }



МСУ Энтити и так генерит репозиторий (контекст). На кой ляд писать обертку над оберткой

С обверкой имхо лучше, тк. позволяет оторваться от жеской привязки к контексту, позволяет вынести общую CRUD логику в общий generic класс, + повторяемые методы так-же лучше вынести в репозиторий а не запрашивать прямо с контроллера. Ну в конце концов не зря же люди юзают репозиторий
http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/
http://www.tugberkugurlu.com/archive/generic-repository-pattern-entity-framework-asp-net-mvc-and-unit-testing-triangle
http://geekswithblogs.net/seanfao/archive/2009/12/03/136680.aspx
http://jaysmith.us/post/Generic-Repository-for-Entity-Framework.aspx
и т.д.

Правда хочется оторвать generic репозиторий от жесткой привязки к контексту, правда тогда придется делать интерфейс самого дженерика, либо без него - тогда юзать интеграционные тесты. Есть вообще другой выход?
...
Рейтинг: 0 / 0
16.09.2012, 01:08
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959111
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
a_titeevну не знаю... я например unitofwork пользую. очень удобно в него выносить отдельные репо, чем потом вспоминать где что и как
Никто не запрещает в UnitOfWork оперировать кодогенерированным контекстом.

Kane_sqlС обверкой имхо лучше, тк. позволяет оторваться от жеской привязки к контексту, позволяет вынести общую CRUD логику в общий generic класс, + повторяемые методы так-же лучше вынести в репозиторий а не запрашивать прямо с контроллера.
Бред сивой кобылы.
1. Зачем отрыватсья от контекста, какую пользу ты от этого получишь?
2. Какая в зад общая CRUD "логика", ты глянь на свой код - по строчке кода в методе. Во-вторых, о какой "общей" CRUD ты говоришь - она и так общая, т.к. была сгенерирована под любые прокси классы контекста (AddObject, DeleteObject, и т.д.)
3. Как это делают нормальные люди, а не студенты без головного мозга - делают прокси контекст (репозиторий), отнаследованный от твоего кодогенерированного контекста. Закладывают по надобности в него таймауты, конфиги и пр. В прикладном коде того же контроллера ты работаешь с этим прокси контекстом и в ус не дуешь.
4. Зачем писать обертку над оберткой, ты просто сам подумай. Другое дело, если ORM не поддерживает кодогенерацию - например в NHibernate действительно приходится писать свои репозитории, за неимением лучшей жизни. В EF и L2S с этим намного лучше.

Kane_sqlНу в конце концов не зря же люди юзают репозиторий
Люди и с 10 этажа прыгают. Пойдешь за ними? Иногда полезно и свою голову на плечах иметь.

Kane_sqlПравда хочется оторвать generic репозиторий от жесткой привязки к контексту, правда тогда придется делать интерфейс самого дженерика, либо без него - тогда юзать интеграционные тесты. Есть вообще другой выход?
Выход есть - не заниматься идиотизмом.
...
Рейтинг: 0 / 0
16.09.2012, 10:26
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959133
Kane_sql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kane_sql
Гость
МСУ, просто хочу разобраться в вопросе, собственно и все, чтобы как раз сделать выводы и как раз иметь свою голову на плечах :)

МСУ1. Зачем отрыватсья от контекста, какую пользу ты от этого получишь?
Для того чтобы выделить бизнес логику и протестировать ее, все-таки взаимодействие через интерфейс репозитория позволит создать какой нибудь InMemoryRepository - таким образом проверить контроллер в отрыве от конкретного уровня доступа к данным.

МСУ2. Какая в зад общая CRUD "логика", ты глянь на свой код - по строчке кода в методе. Во-вторых, о какой "общей" CRUD ты говоришь - она и так общая, т.к. была сгенерирована под любые прокси классы контекста (AddObject, DeleteObject, и т.д.)
А что лучше было бы по твоему писать под каждую сущность свой репозиторий, тем самым дублируя код, вместо создания дженерика?

МСУ3. Как это делают нормальные люди, а не студенты без головного мозга - делают прокси контекст (репозиторий), отнаследованный от твоего кодогенерированного контекста. Закладывают по надобности в него таймауты, конфиги и пр. В прикладном коде того же контроллера ты работаешь с этим прокси контекстом и в ус не дуешь.
Судя по статьям перечисленным выше, нормальные люди так и делают.
Можно пример наследования от кодогенерированного контекста с таймаутами, конфигами и т.д?

МСУ4. Зачем писать обертку над оберткой, ты просто сам подумай.
К примеру встречается у нас какой-нибудь запрос который повторяется в нескольких контроллерах и выполняется к одной сущности, логично было бы вынести его в репозиторий, ладно я понимаю если мы выполняем один специфический запрос единожды - смысла выносить в репозиторий не вижу. Подобный подход жесткой привязки к контексту - не есть хорошо.


МСУ, т.е. по твоему нет смысла в изоляции и тестировании контроллера - потому что в нем мало кода и он намертво связан с кодогенерируемым контекстом?
...
Рейтинг: 0 / 0
16.09.2012, 11:38
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959186
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Kane_sqlМСУ, просто хочу разобраться в вопросе, собственно и все, чтобы как раз сделать выводы и как раз иметь свою голову на плечах :)
Вот это правильно :)

Kane_sqlМСУ1. Зачем отрыватсья от контекста, какую пользу ты от этого получишь?
Для того чтобы выделить бизнес логику и протестировать ее, все-таки взаимодействие через интерфейс репозитория позволит создать какой нибудь InMemoryRepository - таким образом проверить контроллер в отрыве от конкретного уровня доступа к данным.
DAL - это не бизнес-логика и никогда ей не будет, так что там нечего отделять. Ты же пытаешься отделить котлеты от котлет, на выходе - та же самая котлета, только более прожаристей. Выхлоп и КПД от таких манипуляций - нуль.

Kane_sqlМСУ2. Какая в зад общая CRUD "логика", ты глянь на свой код - по строчке кода в методе. Во-вторых, о какой "общей" CRUD ты говоришь - она и так общая, т.к. была сгенерирована под любые прокси классы контекста (AddObject, DeleteObject, и т.д.)
А что лучше было бы по твоему писать под каждую сущность свой репозиторий, тем самым дублируя код, вместо создания дженерика?
Каждая сущность в своем репозитории - это вообще бред сумасшедшего. Есть контекст (он же репозиторий), по сути он представляет собой объектное отображение хранилища. В этом контексте уже всё есть, что нужно для CRUD и даже больше. Вот этот контекст и расширяй дальше, а не плоди генерик-обертки над оберткой и т.п.

Kane_sqlСудя по статьям перечисленным выше, нормальные люди так и делают.
Выбрось на помойку эти статьи, их писали недоросли.

Kane_sqlМожно пример наследования от кодогенерированного контекста с таймаутами, конфигами и т.д?
 
можно
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
public partial class SqlDataRepository : SqlDataContext
{
    private void ApplyBaseSettings()
    {
        CommandTimeout = 36000;
    }

    public SqlRepository()
    {
        ApplyBaseSettings();
    }

    public SqlRepository(RepositoryParameter parameters)
    {
        Connection.ConnectionString = parameters.ConnectionString;
        ...
        ApplyBaseSettings();
    }

    public int Delete<T>(IEnumerable<T> entities) where T : class
    {
        var command = this.GetCommand(entities.AsQueryable());
        string s = this.GetCommand(entities.AsQueryable()).CommandText;
        command.CommandText = "DELETE [t0]\r\n" + s.Substring(s.IndexOf("FROM"));
        command.Connection.Open();
        int records = command.ExecuteNonQuery();
        command.Connection.Close();
        return records;
    }

    ...
}



Тем самым ты можешь до опупения расширять здесь свой репозиторий, который будет означать только одно - маппинг объектов конкретной БД.

Kane_sqlМСУ4. Зачем писать обертку над оберткой, ты просто сам подумай.
К примеру встречается у нас какой-нибудь запрос который повторяется в нескольких контроллерах и выполняется к одной сущности, логично было бы вынести его в репозиторий, ладно я понимаю если мы выполняем один специфический запрос единожды - смысла выносить в репозиторий не вижу. Подобный подход жесткой привязки к контексту - не есть хорошо.
В смысле повторяется один и тот же запрос в нескольких сущностях? Если сущности разные - запросы к ним априори будут другие. Во-вторых, для специфицеских (да и вообще для всех) запросов в котроллере оперировать лямбдой контекста кто-то запрещает? Бери, выдергивай данные из репозитория (контекста), вмапливайся в модель представления (хорошая практика) и вперёд. Какие сложности?

Kane_sqlМСУ, т.е. по твоему нет смысла в изоляции и тестировании контроллера - потому что в нем мало кода и он намертво связан с кодогенерируемым контекстом?
Смысл в тестировании есть всегда, это касается не только контроллера. Смысл в изоляции - я не понимаю, о чем ты - что именно и от кого нужно изолировать?
Если тебе нужен такой-то контекст в контроллере - бери и используй его. Нужно выполнить такой-то запрос - бери и выполняй его в контроллере через тот же генеренный контекст. Контекст - он уже и так является готовой полноценной абстракией с набором вкусных свойств и методов, зачем еще кобыле пятое колесо в виде генерик-педали?
Если же хочется более чистого контроллера (а это тоже нормально), пиши все запросы в своем репозитории, код которого я привел, расширяйся в нем.
...
Рейтинг: 0 / 0
16.09.2012, 13:38
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959219
Фотография a_titeev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_titeev
Участник
JМСУ,

чет я не понимаю. Когда-то я заводил тему о многослойной архитектуре. Мсу, не ты ли писал о том, что реализация dal с отдельными репо, обертывающими дата-контекст “не только логична, но и правильна“. Я кстати практически ту архитектуру сейчас и юзаю, которую тогда описал, только напрямую bl с репо не работает, а через unitofwork.
И еще. зачем напрямую сейчас работать с objectcontext?
...
Рейтинг: 0 / 0
16.09.2012, 14:57
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959221
Kane_sql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kane_sql
Гость
МСУDAL - это не бизнес-логика и никогда ей не будет, так что там нечего отделять. Ты же пытаешься отделить котлеты от котлет, на выходе - та же самая котлета, только более прожаристей. Выхлоп и КПД от таких манипуляций - нуль
Я не говорил что data access layer - это бизнес логика.

МСУКаждая сущность в своем репозитории - это вообще бред сумасшедшего. Есть контекст (он же репозиторий), по сути он представляет собой объектное отображение хранилища. В этом контексте уже всё есть, что нужно для CRUD и даже больше. Вот этот контекст и расширяй дальше, а не плоди генерик-обертки над оберткой и т.п.
Правильно, вот поэтому лучше использовать репозиторий.

МСУТем самым ты можешь до опупения расширять здесь свой репозиторий, который будет означать только одно - маппинг объектов конкретной БД.
Ок, благодарю за пример.

МСУВ смысле повторяется один и тот же запрос в нескольких сущностях?
Ты неправильно прочитал "запрос который повторяется в нескольких контроллерах и выполняется к одной сущности," , в данном случае обеспечивается реюзабельность методов, поэтому для того чтобы по сто раз одно и то-же не повторять в контроллере лучше вывести подобный запрос в общий класс репозитория.

МСУСмысл в тестировании есть всегда, это касается не только контроллера. Смысл в изоляции - я не понимаю, о чем ты - что именно и от кого нужно изолировать? Изоляция необходима для юнит тестирования, в противном случае получаем интеграционный тест. Таким образом унит тестирование без изоляции от других классов невозможно (под изоляцией понимаю инъектирование зависимости через интерфейс ).
Таким образом используя репозиторий возможно взаимодействовать через его интерфейс в отрыве от реализации, тем самым провести модульный тест ( не интеграционный как в твоем случае, хотя такой подход тоже возможен ). Вот собственно в этом задача репозитория/его интерфейса, а не просто изза того что мне захотелось сделать обвертку над обверткой.

Правда если опять же рассматривать зависимость данной "обвертки" от контекста - то так же в данном случае образуется жесткая ссылка на контекст. Видимо не получиться никаким образом разорвать связь классов и инъектировать зависимость от интерфейса.


МСУЕсли тебе нужен такой-то контекст в контроллере - бери и используй его. Нужно выполнить такой-то запрос - бери и выполняй его в контроллере через тот же генеренный контекст. Контекст - он уже и так является готовой полноценной абстракией с набором вкусных свойств и методов, зачем еще кобыле пятое колесо в виде генерик-педали?
Если же хочется более чистого контроллера (а это тоже нормально), пиши все запросы в своем репозитории, код которого я привел, расширяйся в нем. Не получится - противоречие принципам DI.
...
Рейтинг: 0 / 0
16.09.2012, 15:01
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959260
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
a_titeevJМСУ, чет я не понимаю. Когда-то я заводил тему о многослойной архитектуре. Мсу, не ты ли писал о том, что реализация dal с отдельными репо, обертывающими дата-контекст “не только логична, но и правильна“.
А где я утверждаю, что репозиторий в качестве DAL это плохо?

a_titeevЯ кстати практически ту архитектуру сейчас и юзаю, которую тогда описал, только напрямую bl с репо не работает, а через unitofwork.
Причем тут вообще бизнес-логика и UnitOfWork? Этот паттерн нужен для мониторинга изменений данных доменной модели. Собственно, EF и так имеет подобный функционал.

a_titeevИ еще. зачем напрямую сейчас работать с objectcontext?
А кто мне это запрещает и почему это плохо?

Kane_sqlЯ не говорил что data access layer - это бизнес логика.
Твои же слова "для того чтобы выделить бизнес логику" на мой вопрос об отвязывании от контекста. То есть ты хочешь выделить бизнес-логику в своем новоиспеченном репозитории? Если нет, то излагай мысли человеческим языком, чтоб потом не приходилось додумывать.

Kane_sqlПравильно, вот поэтому лучше использовать репозиторий.
Используй, но не репозиторий над репозиторием. А то получается масло масляное - взял тупые методы EF и вынес их в такие же новые тупые методы нового генерик-репозитория. Супер, мозг вскипел от проделанной работы.

Kane_sqlОк, благодарю за пример.
Наследование рулит. А переписывание готового же функционала - пользы никакой.

Kane_sqlТы неправильно прочитал "запрос который повторяется в нескольких контроллерах и выполняется к одной сущности," , в данном случае обеспечивается реюзабельность методов, поэтому для того чтобы по сто раз одно и то-же не повторять в контроллере лучше вывести подобный запрос в общий класс репозитория.
Я ж писал уже - если хочешь более чистый контроллер - вынеси. Но в большинстве случаев нах не нужно - пары строчек лямбд из репозитория дернул и всё. Он у нас отнаследован от контекста, поэтому все запросы будут работать и не нужно постоянно на каждый чих новые методы плодить.

Kane_sqlИзоляция необходима для юнит тестирования, в противном случае получаем интеграционный тест.
У тебя не получится изоляции, ибо ты и так уже прибил к контроллеру репозиторий и его методы. Чтобы полностью отвязаться, кури IoC-контейнер.

Kane_sqlВот собственно в этом задача репозитория/его интерфейса, а не просто изза того что мне захотелось сделать обвертку над обверткой.
Еще раз, тебе никто не мешает пометить свой новый репозиторий (контекст), отнаследованный от кодогенеренного, конкретным интерфейсом. Этот интерфейс ты заколачиваешь в контроллер и горя не знаешь. Но писать заново новую обертку - извини, это тупость.

Kane_sqlПравда если опять же рассматривать зависимость данной "обвертки" от контекста - то так же в данном случае образуется жесткая ссылка на контекст. Видимо не получиться никаким образом разорвать связь классов и инъектировать зависимость от интерфейса.
См. выше про интерфейс.

Kane_sqlНе получится - противоречие принципам DI.
Конкретно, какие противоречия?
...
Рейтинг: 0 / 0
16.09.2012, 16:01
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959277
Фотография a_titeev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_titeev
Участник
МСУa_titeevЯ кстати практически ту архитектуру сейчас и юзаю, которую тогда описал, только напрямую bl с репо не работает, а через unitofwork.
Причем тут вообще бизнес-логика и UnitOfWork? Этот паттерн нужен для мониторинга изменений данных доменной модели. Собственно, EF и так имеет подобный функционал.

ну и Linq2Sql тоже имеет. но вообще не только - конкуренции, да и вообще обслуживание уже скажем бизнес-транзакций.
просто удобно вынести все репозитории туда, и работать на верхнем уровнем уже с ним... собственно, и тестирование отдельных репо смысла не имеет тогда (это уже к вопросу темы).

МСУa_titeevИ еще. зачем напрямую сейчас работать с objectcontext?
А кто мне это запрещает и почему это плохо?

да не плохо, даже рекомендуют если необходимо долезть туда, куда не долезешь через DbContext. но реально, вот как, например, чувак написал как-то - просто избавляет от лишнего "шума"...
...
Рейтинг: 0 / 0
16.09.2012, 16:43
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959309
Kane_sql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kane_sql
Гость
МСУЭнтити и так генерит репозиторий (контекст). На кой ляд писать обертку над оберткой
обертку над оберткой - последнее упоминание о репозитории(обвертке над обветркой), в дальнейшем о нем пошла и речь, а не о контексте.
Kane_sqlС обверкой имхо лучше, тк. позволяет оторваться от жеской привязки к контексту
Соответственно я и отвечаю о значимости обвертки над обверткой(Репозитории). Те. обвертка (Репозиторий) позволяет отделить бизнес логику (Контроллер) и контекст/dal.
Как раз то с твоей стороны мысли не совсем человеческим языком выражены.

МСУУ тебя не получится изоляции
Изоляция репозитория от контроллера получится, т.к. взаимодействия контроллера и данных идет через интерфейс.

Kane_sqlибо ты и так уже прибил к контроллеру репозиторий и его методы
Как раз то я наоборот говорю о необходимости репозитория, и работы через его интерфейс в контроллере. Что позволит создать фейковую реализацию интерфейса в тестах и протестировать контроллер независимо от контекста. А ты пропагандируеш "макаронный код" - связывание контекста и контроллера.

МСУЧтобы полностью отвязаться, кури IoC-контейнер
Не обязательно, отвязаться в данном случае можно и без него, пример из известного тьюториала:
http://nerddinnerbook.s3.amazonaws.com/Part12.htm
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public class DinnersController : Controller {
 
IDinnerRepository dinnerRepository;
 
public DinnersController()
: this(new DinnerRepository()) {
}
 
public DinnersController(IDinnerRepository repository) {
dinnerRepository = repository;
}
...
}



Только в случае с ioc - резолвинг зависимостей идет через ioc-фреймоворк, фабрики и т.д, или руками как в коде чуть выше, ну или в твоем случае вообще никак :) .
Как раз-то здесь взаимодействие идет через репозиторий, или этот тьюторил тоже МСУнедоросли писали

МСУЕще раз, тебе никто не мешает пометить свой новый репозиторий (контекст), отнаследованный от кодогенеренного, конкретным интерфейсом. Этот интерфейс ты заколачиваешь в контроллер и горя не знаешь. Но писать заново новую обертку - извини, это тупость.

Выше ты писал совершенно противопроложное, определись пожалуйста:

МСУВо-вторых, для специфицеских (да и вообще для всех) запросов в котроллере оперировать лямбдой контекста кто-то запрещает?

Оперировать необходимо лямбдой интерфейса репо а не контекста, лямбдой контекста оперирует репо.

Ок, ладно, до пены изо рта я спорить не планирую, таким образом тестировать репозиторий в отрыве от контекста врядли получиться.
...
Рейтинг: 0 / 0
16.09.2012, 17:30
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959312
Kane_sql
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kane_sql
Гость
a_titeevтестирование отдельных репо смысла не имеет тогда (это уже к вопросу темы).
a_titeev, благодарю, хоть кто-то толково ответил на вопрос темы, а не стал с пеной изо рта рассказывать про поджаристые котлеты. :)
...
Рейтинг: 0 / 0
16.09.2012, 17:32
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959340
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
Kane_sql, тестирование репозитория - это функциональные тесты и отдельная история, а не unit tests.


ЗЫ Не трать зря время на бесполезные споры с муслимом. Он может предложить только "макаронный код", ты это уже сам заметил.
...
Рейтинг: 0 / 0
16.09.2012, 18:26
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959390
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
a_titeevну и Linq2Sql тоже имеет. но вообще не только - конкуренции, да и вообще обслуживание уже скажем бизнес-транзакций.
просто удобно вынести все репозитории туда, и работать на верхнем уровнем уже с ним... собственно, и тестирование отдельных репо смысла не имеет тогда (это уже к вопросу темы).
На счет транзакций - согласен, на счет остального прикладного бизнес-кода я не понимаю, зачем использовать UnitOfWork. На счет тестирования - никто не запрещает и load test написать. Так что тестировать можно и даже нужно.

a_titeevда не плохо, даже рекомендуют если необходимо долезть туда, куда не долезешь через DbContext.
Ну о том и речь.

Kane_sqlМСУЭнтити и так генерит репозиторий (контекст). На кой ляд писать обертку над оберткой
обертку над оберткой - последнее упоминание о репозитории(обвертке над обветркой), в дальнейшем о нем пошла и речь, а не о контексте.
Контекст - это такой же репозиторий (в терминах EF, L2S). Внимательнее читай, я писал в скобках.

Kane_sqlСоответственно я и отвечаю о значимости обвертки над обверткой(Репозитории). Те. обвертка (Репозиторий) позволяет отделить бизнес логику (Контроллер) и контекст/dal.
Контроллер - это не бизнес логика. Обертка (репозиторий над репозиторием) ничего у тебя не отделяет, а тупо дублирует логику DAL под другим соусом. Не понимаешь до сих пор?

Kane_sqlКак раз то с твоей стороны мысли не совсем человеческим языком выражены.
Я тебе уже 10 раз повторяю одно и тоже, у тебя проблемы с пониманием.

Kane_sqlМСУУ тебя не получится изоляции
Изоляция репозитория от контроллера получится, т.к. взаимодействия контроллера и данных идет через интерфейс.
Про интерфейс изначально речи не было. Есть 2 вариант - с IoC и без него. Изначально я тебе говорил вшивать в контроллер контекст (репозиторий) и не заморачиваться. Вдобавок я написал, что если нужен чистый контроллер в отвязке от DAL - кури IoC. Что не так? Есть два варианта развития событий, оба они правильные. IoC не панацея, применяется по набодности.

Kane_sqlКак раз то я наоборот говорю о необходимости репозитория, и работы через его интерфейс в контроллере. Что позволит создать фейковую реализацию интерфейса в тестах и протестировать контроллер независимо от контекста. А ты пропагандируеш "макаронный код" - связывание контекста и контроллера.
Ты читаешь ответы через строчку. Смотри выше, нужна независимость - IoC, не нужна - юзай репозиторий напрямую.
Еще раз для тех кто в танке - я тебе говорил о другом, а именно о том, что ты пишешь гавнокод (обертка над оберткой). Как сделать - я тебе показал, через наследование. Тебе еще 10 раз повторить это?

Kane_sqlНе обязательно, отвязаться в данном случае можно и без него, пример из известного тьюториала
Идея одна - интерфейсная зависимость. Как уже ты это сделаешь, второй вопрос.

Kane_sqlТолько в случае с ioc - резолвинг зависимостей идет через ioc-фреймоворк, фабрики и т.д, или руками как в коде чуть выше, ну или в твоем случае вообще никак :) .
Ты читаешь жопой, извини. Если не хватает мозгов осознать то, о чем я говорил - можешь убить себя об стену :)

Kane_sqlВыше ты писал совершенно противопроложное, определись пожалуйста
Что именно противоположное?

Kane_sqlОперировать необходимо лямбдой интерфейса репо а не контекста, лямбдой контекста оперирует репо.
Репозиторий это тот же контекст. Определись с терминологией. Лямбду ты можешь писать как в контроллере так и в репозитории ( отнаследованном от контекста). Вопрос лишь в зависимостях - нужны они или не нужны.

Kane_sqlОк, ладно, до пены изо рта я спорить не планирую, таким образом тестировать репозиторий в отрыве от контекста врядли получиться.
Тестировать репозиторий всегда можно и нужно. Писал выше - тот же нагрузочный тест.

SeVaKane_sql, тестирование репозитория - это функциональные тесты и отдельная история, а не unit tests.
ЗЫ Не трать зря время на бесполезные споры с муслимом. Он может предложить только "макаронный код", ты это уже сам заметил.
О, кухарка вышла на поле боя. Которая месяц назад узнала, что такое MVC. Даже не смешно.
...
Рейтинг: 0 / 0
16.09.2012, 19:32
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959410
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
МальчикСУлицыНа счет транзакций - согласен, на счет остального прикладного бизнес-кода я не понимаю, зачем использовать UnitOfWork. На счет тестирования - никто не запрещает и load test написать. Так что тестировать можно и даже нужно.


Осел не понимает разницы между unit тестами и нагрузочным тестированием, вместо шила предлагает мыло.
Муся , не мудрено, что ты ничего не понимаешь, закончи ПТУ хотя бы
...
Рейтинг: 0 / 0
16.09.2012, 20:08
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959413
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
SeVaОсел не понимает разницы между unit тестами и нагрузочным тестированием, вместо шила предлагает мыло.
Муся , не мудрено, что ты ничего не понимаешь, закончи ПТУ хотя бы
Кухарка что-то про тесты заговорила? Ты еще вчера в терминах MVC путалась, а тут про шило заговорлила. Иди на пенсию, двоешница, не смеши форум своей бездарностью.
...
Рейтинг: 0 / 0
16.09.2012, 20:15
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959441
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
МСУSeVaОсел не понимает разницы между unit тестами и нагрузочным тестированием, вместо шила предлагает мыло.
Муся , не мудрено, что ты ничего не понимаешь, закончи ПТУ хотя бы
Кухарка что-то про тесты заговорила? Ты еще вчера в терминах MVC путалась, а тут про шило заговорлила. Иди на пенсию, двоешница, не смеши форум своей бездарностью.

Муся, путаешь ты и можешь путаться только в своем говнокоде, тк ничего другого не видел.
Кухаркой я тебя первый раз назвал весь давно, с тех пор ничего не изменилось.
Единственное, что тебе удалось осилить за это время - перенять у записных троллей их повадки:

- снисходительное прихлопывание по плечу, мол, подрасти еще, сынок, ты еще ничего не видел. При этом не имея ни малейшего понятия о предмете обсуждения.
- приписывание всякой хрени оппоненту.

Это все на что ты способен. Был муд..м, им и помрешь.

ЗЫ Ты тут все пропагандировал html5, ASp.Net MVC, а сам к ним близко не подходил. Я же последний, когда он был в девичестве WCF Web Api, почти год назад применял
...
Рейтинг: 0 / 0
16.09.2012, 20:59
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959461
Фотография a_titeev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_titeev
Участник
Вместо срача конструктив был бы полезен..
...
Рейтинг: 0 / 0
16.09.2012, 21:32
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959464
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
SeVaМуся, путаешь ты и можешь путаться только в своем говнокоде, тк ничего другого не видел.
Если гавнокодом называть ипринципалы с мембершипом, по тебе давно плачет психушка. Сядь отдышись.

SeVaКухаркой я тебя первый раз назвал весь давно, с тех пор ничего не изменилось.
Кухарка на пенсии - твоё призвание, свыкнись и не зуди.

SeVaЕдинственное, что тебе удалось осилить за это время - перенять у записных троллей их повадки
Повадки могут быть только у млекопетающих типа тебя, которые два слова связать не могут.

SeVaснисходительное прихлопывание по плечу, мол, подрасти еще, сынок, ты еще ничего не видел. При этом не имея ни малейшего понятия о предмете обсуждения.
О, точно про тебя. Как пить дать.

SeVaприписывание всякой хрени оппоненту.
Если оппонент имбицил типа тебя, то да. Ибо.

SeVaЭто все на что ты способен. Был муд..м, им и помрешь.
Ты смешон, пенсионер.

SeVaЗЫ Ты тут все пропагандировал html5, ASp.Net MVC, а сам к ним близко не подходил. Я же последний, когда он был в девичестве WCF Web Api, почти год назад применял
Опять бла-бла с пеной у рта о том, чего вообще не понимаешь. Клоун.
...
Рейтинг: 0 / 0
16.09.2012, 21:35
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959475
Фотография a_titeev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
a_titeev
Участник
Я думаю люди ищут ответы на конкртные вопросы а не срача.
...
Рейтинг: 0 / 0
16.09.2012, 21:52
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959486
Lexxxxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lexxxxx
Участник
a_titeev,

Все, поздно! Теперь скорее всего ветку закроют.
...
Рейтинг: 0 / 0
16.09.2012, 22:13
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959513
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
[quot МСУ]SeVaМуся, путаешь ты и можешь путаться только в своем говнокоде, тк ничего другого не видел.
Если гавнокодом называть ипринципалы с мембершипом, по тебе давно плачет психушка. Сядь отдышись.

SeVa

Гнидка(или кто ты там сейчас), не приписывай мне свой бред. Только ты это можешь смешивать
...
Рейтинг: 0 / 0
16.09.2012, 22:50
| Ответить | Цитировать | Написать  
EF Нужно ли изолировать и тестировать класс репозитория.
    #37959514
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
SeVaГнидка(или кто ты там сейчас), не приписывай мне свой бред. Только ты это можешь смешивать
Клоун-старпёр, у тебя руки дружат, спойлеры разбежались в разные стороны. Иди выкури папироску и прямиком на пенсию, твой мозг не в состоянии даже элементарное осилить.
...
Рейтинг: 0 / 0
16.09.2012, 22:52
| Ответить | Цитировать | Написать  
25 сообщений из 48, страница 1 из 2
  1  все
Форумы / ADO.NET, LINQ, Entity Framework, NHibernate, DAL, ORM [игнор отключен] [закрыт для гостей] / EF Нужно ли изолировать и тестировать класс репозитория.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=17&fpage=31&tid=1350243]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 178ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 57ms
get tp. blocked users:
 1ms
others: 14ms
total:  294ms
созд. / загр.: 294ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]