Кто-нибудь знает, может ли Unity при разрешении скажем параметра конструктора типа A разрешить значение этого параметра из другого типа B путем вызова функции?
На примере:
public class X
{
public X(A a)
{
..
}
}
Реально инициализирую объект как-то так:
var x = new X( Helper.A_from_B(new B(...)));
Вызов этого Helper.A_from_B в конфиг контейнера никак не передать?
Здравствуйте, sergunok, Вы писали:
S>Кто-нибудь знает, может ли Unity при разрешении скажем параметра конструктора типа A разрешить значение этого параметра из другого типа B путем вызова функции?
S>На примере:
S>public class X S>{ S> public X(A a) S> { S> .. S> } S>}
S>Реально инициализирую объект как-то так: S>var x = new X( Helper.A_from_B(new B(...)));
S>Вызов этого Helper.A_from_B в конфиг контейнера никак не передать?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Кто-нибудь знает, может ли Unity при разрешении скажем параметра конструктора типа A разрешить значение этого параметра из другого типа B путем вызова функции?
S>>На примере:
S>>public class X S>>{ S>> public X(A a) S>> { S>> .. S>> } S>>}
S>>Реально инициализирую объект как-то так: S>>var x = new X( Helper.A_from_B(new B(...)));
S>>Вызов этого Helper.A_from_B в конфиг контейнера никак не передать?
G>Через фабрики
Спасибо!
Сейчас попробую поиспользовать-посмотреть подойдет ли для моего случая..
А через конфиг-файл можно указать используемый fqactory-метод?
До этого пробовал использовать конвертер типа, но столкнулся с тем, что он ограничен (инстанс самого конвертера вроде как не инджектируется, строго создается конструктором без параметров).
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Кто-нибудь знает, может ли Unity при разрешении скажем параметра конструктора типа A разрешить значение этого параметра из другого типа B путем вызова функции?
S>>На примере:
S>>public class X S>>{ S>> public X(A a) S>> { S>> .. S>> } S>>}
S>>Реально инициализирую объект как-то так: S>>var x = new X( Helper.A_from_B(new B(...)));
S>>Вызов этого Helper.A_from_B в конфиг контейнера никак не передать?
G>Через фабрики
Увы, мне не поможет.
Вот тут я некорректно сформулировал: S>>var x = new X( Helper.A_from_B(new B(...)));
Helper — не статичен.. Сам может ресолвится контейнером.
var helper = Helper(...);
var x = new X( helper.A_from_string("some value"));
Мне бы подошел typeConverter, который можно указывать у value в param constructor,
Здравствуйте, sergunok, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sergunok, Вы писали:
S>>>Кто-нибудь знает, может ли Unity при разрешении скажем параметра конструктора типа A разрешить значение этого параметра из другого типа B путем вызова функции?
S>>>На примере:
S>>>public class X S>>>{ S>>> public X(A a) S>>> { S>>> .. S>>> } S>>>}
S>>>Реально инициализирую объект как-то так: S>>>var x = new X( Helper.A_from_B(new B(...)));
S>>>Вызов этого Helper.A_from_B в конфиг контейнера никак не передать?
G>>Через фабрики
S>Увы, мне не поможет.
S>Вот тут я некорректно сформулировал: S>>>var x = new X( Helper.A_from_B(new B(...)));
S>Helper — не статичен.. Сам может ресолвится контейнером.
S>var helper = Helper(...);
S>var x = new X( helper.A_from_string("some value"));
А так:
container.RegisterFactory<IX>(c => c.Resolve<IHelper>().FromString(c.Resolve<string>("string in config")))
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, sergunok, Вы писали:
S>>>>Кто-нибудь знает, может ли Unity при разрешении скажем параметра конструктора типа A разрешить значение этого параметра из другого типа B путем вызова функции?
S>>>>На примере:
S>>>>public class X S>>>>{ S>>>> public X(A a) S>>>> { S>>>> .. S>>>> } S>>>>}
S>>>>Реально инициализирую объект как-то так: S>>>>var x = new X( Helper.A_from_B(new B(...)));
S>>>>Вызов этого Helper.A_from_B в конфиг контейнера никак не передать?
G>>>Через фабрики
S>>Увы, мне не поможет.
S>>Вот тут я некорректно сформулировал: S>>>>var x = new X( Helper.A_from_B(new B(...)));
S>>Helper — не статичен.. Сам может ресолвится контейнером.
S>>var helper = Helper(...);
S>>var x = new X( helper.A_from_string("some value"));
G>А так:
G>
G>container.RegisterFactory<IX>(c => c.Resolve<IHelper>().FromString(c.Resolve<string>("string in config")))
G>
В моем случае не хочется сами константы "string in config" прописывать в коде.
Привожу более жизненный пример того, что хочется поинжектить.
Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц.
Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно.
Я злоупотребляю DI? Стоит взглянуть на что-то кроме Unity?
interface IServer
{
Page Download(string name);
}
class Server : IServer
{
Server(string host, int port);
}
interface IParser
{
void ParseAll();
}
class Parser : IParser
{
Parser(IEnumerable<IPage> pages);
void ParseAll();
}
IServer server = new Server("myhost", 1234);
IParser parser = new Parser(
new List<IPage>() {
server.Download("a.txt"),
server.Download("b.txt"),
server.Download("c.txt"),
server.Download("d.txt")
});
Здравствуйте, sergunok, Вы писали:
S>Привожу более жизненный пример того, что хочется поинжектить. S>Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц.
имена страниц лучше где-нить отдельно задавать, а не в контейнере
S>Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно.
Непонятно... Напиши как ты хочешь чтобы это выглядело.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Привожу более жизненный пример того, что хочется поинжектить. S>>Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц. G>имена страниц лучше где-нить отдельно задавать, а не в контейнере
почему?
S>>Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно. G>Непонятно... Напиши как ты хочешь чтобы это выглядело.
хочется всегда одного, чтобы приложение для разных случаев использования конфигурировалось в XML-файле, желательно в одном.
Здравствуйте, sergunok, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sergunok, Вы писали:
S>>>Привожу более жизненный пример того, что хочется поинжектить. S>>>Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц. G>>имена страниц лучше где-нить отдельно задавать, а не в контейнере S>почему?
Потому что контейнер оперирует типами, в крайнем случае парами (тип, имя), а строки зачастую содержат семантику, которая не выражается типами и именами.
S>>>Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно. G>>Непонятно... Напиши как ты хочешь чтобы это выглядело. S>хочется всегда одного, чтобы приложение для разных случаев использования конфигурировалось в XML-файле, желательно в одном.
Не стоит, а то получится программирование в XML, это гораздо тяжелее чем программировать на C#.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, sergunok, Вы писали:
S>>>>Привожу более жизненный пример того, что хочется поинжектить. S>>>>Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц. G>>>имена страниц лучше где-нить отдельно задавать, а не в контейнере S>>почему? G>Потому что контейнер оперирует типами, в крайнем случае парами (тип, имя), а строки зачастую содержат семантику, которая не выражается типами и именами.
S>>>>Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно. G>>>Непонятно... Напиши как ты хочешь чтобы это выглядело. S>>хочется всегда одного, чтобы приложение для разных случаев использования конфигурировалось в XML-файле, желательно в одном. G>Не стоит, а то получится программирование в XML, это гораздо тяжелее чем программировать на C#.
G>http://gandjustas.blogspot.com/2009/01/unity_8026.html
Наверное вопрос в том: должен ли контейнер быть самодостаточным для конфигурации приложения..
Или же его роль — только помощь в конфигурировании IoC (т.е. только позволять определять конкретные типы, реализующие интерфейсы).
На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте,
причем конфиугрировать все: и константы и типы и объекты типов и их коллекции.
Здравствуйте, sergunok, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sergunok, Вы писали:
S>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, sergunok, Вы писали:
S>>>>>Привожу более жизненный пример того, что хочется поинжектить. S>>>>>Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц. G>>>>имена страниц лучше где-нить отдельно задавать, а не в контейнере S>>>почему? G>>Потому что контейнер оперирует типами, в крайнем случае парами (тип, имя), а строки зачастую содержат семантику, которая не выражается типами и именами.
S>>>>>Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно. G>>>>Непонятно... Напиши как ты хочешь чтобы это выглядело. S>>>хочется всегда одного, чтобы приложение для разных случаев использования конфигурировалось в XML-файле, желательно в одном. G>>Не стоит, а то получится программирование в XML, это гораздо тяжелее чем программировать на C#.
G>>http://gandjustas.blogspot.com/2009/01/unity_8026.html
S>Наверное вопрос в том: должен ли контейнер быть самодостаточным для конфигурации приложения.. S>Или же его роль — только помощь в конфигурировании IoC (т.е. только позволять определять конкретные типы, реализующие интерфейсы).
Что значит "самодостаточный" и "помощь в конфигурировании"?
http://gandjustas.blogspot.com/2009/01/ioc_20.html
S>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции.
Для этого есть самый обычный конфиг.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, sergunok, Вы писали:
S>>>>Здравствуйте, gandjustas, Вы писали:
G>>>>>Здравствуйте, sergunok, Вы писали:
S>>>>>>Привожу более жизненный пример того, что хочется поинжектить. S>>>>>>Нужна возможность с легкостью оперировать разными значениями параметров сервера и именами страниц. G>>>>>имена страниц лучше где-нить отдельно задавать, а не в контейнере S>>>>почему? G>>>Потому что контейнер оперирует типами, в крайнем случае парами (тип, имя), а строки зачастую содержат семантику, которая не выражается типами и именами.
S>>>>>>Если с коллекцией объектов в Unity видимо вопрос можно как-то решить, то вот с вызовом метода Download — непонятно. G>>>>>Непонятно... Напиши как ты хочешь чтобы это выглядело. S>>>>хочется всегда одного, чтобы приложение для разных случаев использования конфигурировалось в XML-файле, желательно в одном. G>>>Не стоит, а то получится программирование в XML, это гораздо тяжелее чем программировать на C#.
G>>>http://gandjustas.blogspot.com/2009/01/unity_8026.html
S>>Наверное вопрос в том: должен ли контейнер быть самодостаточным для конфигурации приложения.. S>>Или же его роль — только помощь в конфигурировании IoC (т.е. только позволять определять конкретные типы, реализующие интерфейсы). G>Что значит "самодостаточный" и "помощь в конфигурировании"?
"самодостаточный" = не требующий дополнительных средств для конфигурирования приложения типа "обычного конфига"
G>http://gandjustas.blogspot.com/2009/01/ioc_20.html
S>>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции. G>Для этого есть самый обычный конфиг.
В этом-то и неудобство, что что-то нужно делать в конфиге, что-то в настройках Unity и пусть даже они могут находиться в одном файле.
Здравствуйте, sergunok, Вы писали:
S>>>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>>>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции. G>>Для этого есть самый обычный конфиг. S>В этом-то и неудобство, что что-то нужно делать в конфиге, что-то в настройках Unity и пусть даже они могут находиться в одном файле.
Так это один и тот же конфиг...
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>>>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>>>>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции. G>>>Для этого есть самый обычный конфиг. S>>В этом-то и неудобство, что что-то нужно делать в конфиге, что-то в настройках Unity и пусть даже они могут находиться в одном файле. G>Так это один и тот же конфиг...
Да, но если уж я в нем описываю перечь имен файлов для скачивания для данного сценария и для каждого файла еще что-нибудь, например тип компонента, отвечающего за скачивание, хочется чтоб это не было разбросано по разным частям конфига — одно просто в конфиге, другое в секции Unity..
Здравствуйте, sergunok, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sergunok, Вы писали:
S>>>>>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>>>>>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции. G>>>>Для этого есть самый обычный конфиг. S>>>В этом-то и неудобство, что что-то нужно делать в конфиге, что-то в настройках Unity и пусть даже они могут находиться в одном файле. G>>Так это один и тот же конфиг... S>Да, но если уж я в нем описываю перечь имен файлов для скачивания для данного сценария и для каждого файла еще что-нибудь, например тип компонента, отвечающего за скачивание, хочется чтоб это не было разбросано по разным частям конфига — одно просто в конфиге, другое в секции Unity..
По-моему ты уже начал программировать в xml. Бросай это дело, на C# проще.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, sergunok, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, sergunok, Вы писали:
S>>>>>>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>>>>>>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции. G>>>>>Для этого есть самый обычный конфиг. S>>>>В этом-то и неудобство, что что-то нужно делать в конфиге, что-то в настройках Unity и пусть даже они могут находиться в одном файле. G>>>Так это один и тот же конфиг... S>>Да, но если уж я в нем описываю перечь имен файлов для скачивания для данного сценария и для каждого файла еще что-нибудь, например тип компонента, отвечающего за скачивание, хочется чтоб это не было разбросано по разным частям конфига — одно просто в конфиге, другое в секции Unity..
G>По-моему ты уже начал программировать в xml. Бросай это дело, на C# проще.
Не-не. Все, что надо уже сделано на смеси C#, Unity и конфига. Это лишь рассуждения об идеале
Здравствуйте, sergunok, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, sergunok, Вы писали:
S>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, sergunok, Вы писали:
S>>>>>>>На мой взгляд, в Unity сделали больше чем только IoC, но и сильно меньше, чем нужно для конфигурирования. А конфигурировать всяко удобно в одном месте, S>>>>>>>причем конфиугрировать все: и константы и типы и объекты типов и их коллекции. G>>>>>>Для этого есть самый обычный конфиг. S>>>>>В этом-то и неудобство, что что-то нужно делать в конфиге, что-то в настройках Unity и пусть даже они могут находиться в одном файле. G>>>>Так это один и тот же конфиг... S>>>Да, но если уж я в нем описываю перечь имен файлов для скачивания для данного сценария и для каждого файла еще что-нибудь, например тип компонента, отвечающего за скачивание, хочется чтоб это не было разбросано по разным частям конфига — одно просто в конфиге, другое в секции Unity..
G>>По-моему ты уже начал программировать в xml. Бросай это дело, на C# проще. S>Не-не. Все, что надо уже сделано на смеси C#, Unity и конфига. Это лишь рассуждения об идеале
