ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / WPF, Silverlight [игнор отключен] [закрыт для гостей] / IoC-контейнер для использования с MVVM: где хранить?
25 сообщений из 97, страница 2 из 4
  2  все
IoC-контейнер для использования с MVVM: где хранить?
    #38311391
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
SolYUtorМСУ,

контейнеры склонны контролировать жизненный цикл созданных ими объектов. Во многих случаях требуется явно указать контейнеру, когда объект можно уничтожать. Register-Resolve-Release цикл. Так вот, DependencyResolver не предоставляет способа "отпускать" объекты.Всегда стараюсь управлять временем жизни через using. Пока получается. :-)
...
Рейтинг: 0 / 0
26.06.2013, 15:10
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311440
SolYUtor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SolYUtor
Участник
Алексей КВсегда стараюсь управлять временем жизни через using. Пока получается. :-)
Без контейнера получается. С контейнером будет утечка памяти.
...
Рейтинг: 0 / 0
26.06.2013, 15:35
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311442
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
SolYUtorконтейнеры склонны контролировать жизненный цикл созданных ими объектов.
Я в курсе, но мне это не нужно. Я плохой?
...
Рейтинг: 0 / 0
26.06.2013, 15:37
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311454
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
МСУSolYUtorконтейнеры склонны контролировать жизненный цикл созданных ими объектов.
Я в курсе, но мне это не нужно. Я плохой?
В терминологии MVC мне достаточно такого варианта:

Код: 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.
public class BaseController : Controller
{
    private IDataService _service;
    public IDataService Service
    {
        get
        {
            if (_service == null)
            {
                _service = DependencyResolver.Current.GetService<IDataService>();
            }

            return _service;
        }
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);

        if (disposing && _service != null)
        {
            _service.Dispose();
        }
    }
}



SolYUtor, объясни, зачем мне тут полновесный DI?
...
Рейтинг: 0 / 0
26.06.2013, 15:42
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311475
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
МСУSeVaЭта унылая шняго из ASP.net mvc создана только для таких как MCУ, который в глаза не видел нормальные контейнеры.
Это замечательный возможность использовать штатный mvc-шный резолвер. А те, вроде тебя, у кого не хватает мозгов это понять, могут вещать дальше о правильный контейнерах и убитой кастрированной поделке prism.

Штатный резолвер для убогих, натуральный анти-паттерн, который нужно за собой везде таскать или создавать еще один маразм - глобальную ссылку(в mvc - это конфиг, которым ты везде тычешь). Нужен только по одной причине - есть ряд сущностей, которые нужны не всегда(например, упомянутый IMessageBoxService, который необходимо получить только при возникновении ошибки, которая в свою очередь может быть раз в сто лет), чтобы этого не происходило нормальные контейнеры реализуют возможность отложенной инжекции(Lazy в MEF&Unity3.0). Если это есть, то твой резолвер и даром не нать, советы опытных собаководов с фабриками тоже идут лесом.
...
Рейтинг: 0 / 0
26.06.2013, 15:52
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311492
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
SeVaШтатный резолвер для убогих
Штатный резолвер для тех, кому не нужно большее. Этим убогим не понять, всё сложно.
Для более уточненных задач есть штатный IControllerFactory.

SeVaнатуральный анти-паттерн, который нужно за собой везде таскать
Что, куда и зачем нужно таскать? Внятно сформулируй мысль.

SeVaглобальную ссылку(в mvc - это конфиг, которым ты везде тычешь).
Ты чего там у себя куришь? Какая глобальная ссылка?
...
Рейтинг: 0 / 0
26.06.2013, 16:00
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311496
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
МСУМСУпропущено...

Я в курсе, но мне это не нужно. Я плохой?
В терминологии MVC мне достаточно такого варианта:

Код: 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.
public class BaseController : Controller
{
    private IDataService _service;
    public IDataService Service
    {
        get
        {
            if (_service == null)
            {
                _service = DependencyResolver.Current.GetService<IDataService>();
            }

            return _service;
        }
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);

        if (disposing && _service != null)
        {
            _service.Dispose();
        }
    }
}



SolYUtor, объясни, зачем мне тут полновесный DI?

1. Этот говнокод непереносим из-за жесткой ссылки на статик
2. Ты тут недавно поднимал визг, когда Нахлобуч явно диспозил объекты(жалко я был забанен в это время, ReadAllBytes меня тоже очень порадовал). Твой очередной говносовет не прокатит в весьма простых и часто используемых случаях, когда нужно одно соединение с БД, транзакция, etc per Request(таких вариантов вагон и маленькая тележка, но ты об этом не знаешь со своими говнообработчиками в ASP.net). В нормальных контейнерах можно задать зависимости для per Request, объекты будут создаваться и удалятся на автомате.
...
Рейтинг: 0 / 0
26.06.2013, 16:01
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311499
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
МСУSeVaШтатный резолвер для убогих
Штатный резолвер для тех, кому не нужно большее. Этим убогим не понять, всё сложно.
Для более уточненных задач есть штатный IControllerFactory.

SeVaнатуральный анти-паттерн, который нужно за собой везде таскать
Что, куда и зачем нужно таскать? Внятно сформулируй мысль.

SeVaглобальную ссылку(в mvc - это конфиг, которым ты везде тычешь).
Ты чего там у себя куришь? Какая глобальная ссылка?

Обычная история с твоей тупостью и не пониманием простых вещей.
Попробуй в своем говнокоде обойтись без статиков на твой ресолвер, а потом нам расскажи как ты будешь это делать.
...
Рейтинг: 0 / 0
26.06.2013, 16:04
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311506
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУ
Код: 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.
public class BaseController : Controller
{
    private IDataService _service;
    public IDataService Service
    {
        get
        {
            if (_service == null)
            {
                _service = DependencyResolver.Current.GetService<IDataService>();
            }

            return _service;
        }
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);

        if (disposing && _service != null)
        {
            _service.Dispose();
        }
    }
}

А что там диспозить? Собрался DbConnection или FileStream делать членом класса сервиса? Да и вообще, layer superclass для слоя прикладных сервисов - тупиковый путь развития.
...
Рейтинг: 0 / 0
26.06.2013, 16:06
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311508
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
SolYUtorАлексей КВсегда стараюсь управлять временем жизни через using. Пока получается. :-)
Без контейнера получается. С контейнером будет утечка памяти.Смотря какой LifetimeManager.
...
Рейтинг: 0 / 0
26.06.2013, 16:07
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311526
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
SeVa1. Этот говнокод непереносим из-за жесткой ссылки на статик
2. Ты тут недавно поднимал визг, когда Нахлобуч явно диспозил объекты(жалко я был забанен в это время, ReadAllBytes меня тоже очень порадовал). Твой очередной говносовет не прокатит в весьма простых и часто используемых случаях, когда нужно одно соединение с БД, транзакция, etc per Request(таких вариантов вагон и маленькая тележка, но ты об этом не знаешь со своими говнообработчиками в ASP.net). В нормальных контейнерах можно задать зависимости для per Request, объекты будут создаваться и удалятся на автомате.
1. Тут нет никаких жестких ссылок на статик. Через штатный DependencyResolver по ленивому свойству я получаю экземпляр, который сидит себе в атрибутах контроллера.
2. Твои говномысли опять размазались по планете и здравой логике не поддаются. Соберись.

SeVaОбычная история с твоей тупостью и не пониманием простых вещей.
Попробуй в своем говнокоде обойтись без статиков на твой ресолвер, а потом нам расскажи как ты будешь это делать.
Стандартная ситуация, когда ты захлебываешься в своем же поносе. Чем тебя так испугал статический резолв?
...
Рейтинг: 0 / 0
26.06.2013, 16:13
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311534
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Алексей КА что там диспозить? Собрался DbConnection или FileStream делать членом класса сервиса? Да и вообще, layer superclass для слоя прикладных сервисов - тупиковый путь развития.
Например, DbConnection. Во-вторых, если страшен layer superclass, никто не запрещает тоже самое писать в наследниках. В-третьих, чем layer superclass опасен?
...
Рейтинг: 0 / 0
26.06.2013, 16:14
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311610
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУАлексей КА что там диспозить? Собрался DbConnection или FileStream делать членом класса сервиса? Да и вообще, layer superclass для слоя прикладных сервисов - тупиковый путь развития.
Например, DbConnection. Во-вторых, если страшен layer superclass, никто не запрещает тоже самое писать в наследниках. В-третьих, чем layer superclass опасен?Я как-то упёрся в прикладных сервисах в необходимость наследования от нескольких layer superclass. Понадобились одновременно DbContext, описанный примерно как в твоём примере, и ещё одна канитель, описанная в другом суперклассе. Вроде как получилось нарушение SRP со всеми вытекающими. После этого решил больше так не делать.

Далее, если я привяжу управление временем жизни контейнера (и созданных ими сервисов) к WCF (ASP.Net) сессии через IInstanceProvider (или аналогичное), возможна ситуация когда это не устроит.

Не, явное управление временем жизни через using - самое гибкое решение. Всё остальное от лукавого...

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
class MyService
{
    public void Do()
    {
        using(var connection = MyConnectionFactory.GetConnection())
        {
    
        }
    }
}


MyConnectionFactory неуправляемых ресурсов не содержит. Его можно инжектировать, можно использовать статический. Зависит от уровня маразма и потребностей.
...
Рейтинг: 0 / 0
26.06.2013, 16:44
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311636
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Алексей КЯ как-то упёрся в прикладных сервисах в необходимость наследования от нескольких layer superclass. Понадобились одновременно DbContext, описанный примерно как в твоём примере, и ещё одна канитель, описанная в другом суперклассе. Вроде как получилось нарушение SRP со всеми вытекающими. После этого решил больше так не делать.
А расшириться через конструктор почему не захотел? :) А в регистрации подпихиваешь готовую ссылку в конструктор.

Алексей КДалее, если я привяжу управление временем жизни контейнера (и созданных ими сервисов) к WCF (ASP.Net) сессии через IInstanceProvider (или аналогичное), возможна ситуация когда это не устроит.
Не, явное управление временем жизни через using - самое гибкое решение. Всё остальное от лукавого...
Ну не скажи. Яркий пример фабрики контроллеров, о которой писал SolYUtor:

Код: 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.
public class HomeController : Controller
{
    private IDataService DataService;

    [DefaultConstructor]
    public HomeController(IDataService service)
    {
        this.DataService = service;
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        if (disposing && DataService != null)
        {
            DataService.Dispose();
        }
    }

    public ActionResult Index()
    {
        // Use DataService ...
        return View(model);
    }

    public ActionResult Index2()
    {
        // User DataService...
        return View(model);
    }
}



И никаких юзингов. Честное управление жизнью моих зависимостей.

P.S. Примерно тоже самое и я предлагаю, только без фабрики. Вариант с фабрикой более утонченный :)
...
Рейтинг: 0 / 0
26.06.2013, 16:57
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311673
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
МСУА расшириться через конструктор почему не захотел? :) А в регистрации подпихиваешь готовую ссылку в конструктор.Побоялся плодить бесконечное количество конструкторов. :-)

МСУАлексей КДалее, если я привяжу управление временем жизни контейнера (и созданных ими сервисов) к WCF (ASP.Net) сессии через IInstanceProvider (или аналогичное), возможна ситуация когда это не устроит.
Не, явное управление временем жизни через using - самое гибкое решение. Всё остальное от лукавого...
Ну не скажи. Яркий пример фабрики контроллеров, о которой писал SolYUtor:SolYUtorIDependencyResolver в MVC - это ошибка. Правильный путь - реализовывать IControllerFactory.Редкий случай, когда я согласен с SolYUtor.

SolYUtor
Код: 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.
public class HomeController : Controller
{
    private IDataService DataService;

    [DefaultConstructor]
    public HomeController(IDataService service)
    {
        this.DataService = service;
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        if (disposing && DataService != null)
        {
            DataService.Dispose();
        }
    }

    public ActionResult Index()
    {
        // Use DataService ...
        return View(model);
    }

    public ActionResult Index2()
    {
        // User DataService...
        return View(model);
    }
}

Это гораздо лучше, нет базового класса, отвечающего за доступ к инфраструктуре. Осталось заменить IDataService на IDataServiceFactory и честно использовать using. :-)

МСУИ никаких юзингов. Честное управление жизнью моих зависимостей.А потом захочется иметь два одновременных коннекта к одной базе и начнутся поиски "кто виноват и что делать". :-)
...
Рейтинг: 0 / 0
26.06.2013, 17:17
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311674
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
Алексей КМСУпропущено...

Например, DbConnection. Во-вторых, если страшен layer superclass, никто не запрещает тоже самое писать в наследниках. В-третьих, чем layer superclass опасен?Я как-то упёрся в прикладных сервисах в необходимость наследования от нескольких layer superclass. Понадобились одновременно DbContext, описанный примерно как в твоём примере, и ещё одна канитель, описанная в другом суперклассе. Вроде как получилось нарушение SRP со всеми вытекающими. После этого решил больше так не делать.

Далее, если я привяжу управление временем жизни контейнера (и созданных ими сервисов) к WCF (ASP.Net) сессии через IInstanceProvider (или аналогичное), возможна ситуация когда это не устроит.

Не, явное управление временем жизни через using - самое гибкое решение. Всё остальное от лукавого...

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
class MyService
{
    public void Do()
    {
        using(var connection = MyConnectionFactory.GetConnection())
        {
    
        }
    }
}


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

На утрированном примере попробую объяснить почему это лажа.
1. MyConnectionFactory - это только лишний класс и усложнение кода на ровном месте, которые никому не нужны.
2. Предположим, что connection нужен для двух repositories и в один прекрасный момент мы решаем заменить их реализацию с ADO на EF, что подребует DBContext вместо Connection и нужно будет лопатить код, а с di этого ненужно будет делать.

ЗЫ 2Муслима, твои очередные брызги даже читать не буду, ничего там кроме говна не будет.
...
Рейтинг: 0 / 0
26.06.2013, 17:17
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311687
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
SeVaНа утрированном примере попробую объяснить почему это лажа.
1. MyConnectionFactory - это только лишний класс и усложнение кода на ровном месте, которые никому не нужны.Предположим.

SeVa2. Предположим, что connection нужен для двух repositoriesВнутри фабрики будет применён ThreadStatic.

SeVaи в один прекрасный момент мы решаем заменить их реализацию с ADO на EF, что подребует DBContext вместо Connection и нужно будет лопатить кодКакая-то дикая ситуация, но не придётся, потому что "это" между методами/классами таскаться не будет. См выше про ThreadStatic.

SeVaа с di этого ненужно будет делать.Верю. :-)
...
Рейтинг: 0 / 0
26.06.2013, 17:27
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311724
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
Алексей КSeVaНа утрированном примере попробую объяснить почему это лажа.
1. MyConnectionFactory - это только лишний класс и усложнение кода на ровном месте, которые никому не нужны.Предположим.

SeVa2. Предположим, что connection нужен для двух repositoriesВнутри фабрики будет применён ThreadStatic.

SeVaи в один прекрасный момент мы решаем заменить их реализацию с ADO на EF, что подребует DBContext вместо Connection и нужно будет лопатить кодКакая-то дикая ситуация, но не придётся, потому что "это" между методами/классами таскаться не будет. См выше про ThreadStatic.

SeVaа с di этого ненужно будет делать.Верю. :-)

С await твои ThreadStatic из пещер идут лесом.
...
Рейтинг: 0 / 0
26.06.2013, 18:02
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311727
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
SeVaС await твои ThreadStatic из пещер идут лесом.Это да. Но нужен ли он на сервере?
...
Рейтинг: 0 / 0
26.06.2013, 18:04
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311816
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
Алексей КSeVaС await твои ThreadStatic из пещер идут лесом.Это да. Но нужен ли он на сервере?

Прежде всего он нужен именно там, пока идут запросы в БД, внешние сервисы и тд, треды не расходуются, получается совсем другая нагрузочная способность. Проверено
...
Рейтинг: 0 / 0
26.06.2013, 19:09
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311832
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
SeVaпока идут запросы в БД, внешние сервисы и тд, треды не расходуются,Я в курсе.
SeVaполучается совсем другая нагрузочная способность.А оно того стоит? Может проще (дешевле? надёжнее?) горизонтально масштабировать сервера приложений?

На клиенте заморочек с асинхронностями хватает. А на сервере часто непростая логика. Если к ней добавить ещё асинхронностей - вообще жесть получится...

Попутно вопрос. Как при всех этих асинхронностях работает OperationContext в WCF? Он вроде как тоже на ThreadStatic построен?
...
Рейтинг: 0 / 0
26.06.2013, 19:30
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311854
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
Алексей КПопутно вопрос. Как при всех этих асинхронностях работает OperationContext в WCF? Он вроде как тоже на ThreadStatic построен?Как и предполагалось, для OperationContext + await таки нужен костыль .
...
Рейтинг: 0 / 0
26.06.2013, 19:53
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38311865
SeVa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SeVa
Участник
Алексей КSeVaпока идут запросы в БД, внешние сервисы и тд, треды не расходуются,Я в курсе.
SeVaполучается совсем другая нагрузочная способность.А оно того стоит? Может проще (дешевле? надёжнее?) горизонтально масштабировать сервера приложений?

На клиенте заморочек с асинхронностями хватает. А на сервере часто непростая логика. Если к ней добавить ещё асинхронностей - вообще жесть получится...

Попутно вопрос. Как при всех этих асинхронностях работает OperationContext в WCF? Он вроде как тоже на ThreadStatic построен?

Полная жесть - мультики с OperationContext. Для чего тебе это было нужно?
...
Рейтинг: 0 / 0
26.06.2013, 20:12
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38312061
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей К
Участник
[quot SeVa]Алексей КПолная жесть - мультики с OperationContext.Да.
SeVaДля чего тебе это было нужно?Читай внимательнее. Мне это не было нужно. И, надеюсь, не будет. Любопытство, не более...
...
Рейтинг: 0 / 0
27.06.2013, 05:54
| Ответить | Цитировать | Написать  
IoC-контейнер для использования с MVVM: где хранить?
    #38312163
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
МСУ
Участник
Алексей КПобоялся плодить бесконечное количество конструкторов. :-)
Два конструктора это бесконечность? :) Вообще да, береги конструкторы с молоду (с)

Алексей КА потом захочется иметь два одновременных коннекта к одной базе и начнутся поиски "кто виноват и что делать". :-)

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
public class HomeController : Controller
{
    private IDataService DataService;
    private IDataService2 DataService2;

    [DefaultConstructor]
    public HomeController(IDataService service, IDataService2 service2)
    {
        this.DataService = service;
        this.DataService2 = service2;
    }

    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        if (disposing)
        {
            DataService.Dispose();
            DataService2.Dispose();
        }
    }
}



Зло? )

P.S. Долбосева, даже не хочу что-то тебе доказывать. Кроме очередного слюновыделения и какого-то бреда про статику от тебя нечего ожидать.
...
Рейтинг: 0 / 0
27.06.2013, 09:48
| Ответить | Цитировать | Написать  
25 сообщений из 97, страница 2 из 4
  2  все
Форумы / WPF, Silverlight [игнор отключен] [закрыт для гостей] / IoC-контейнер для использования с MVVM: где хранить?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=21&msg=38311832&tid=1441308]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 48ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 59ms
get tp. blocked users:
 1ms
others: 10ms
total:  158ms
созд. / загр.: 158ms
x
x
Закрыть


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