|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КLRНу давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.Зачем нужно "почти", если есть стандартное TPL. +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:07 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КMonochromatiqueПро асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?Никак. Надо сразу делать асинхронным.Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным. Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:18 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МСУMonochromatiqueОдин программист создает следующий интерфейс: IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces(); И программист его реализует и всё работает. Реализует через функцию SDK IEnumerable<NetworkInterfaceInfo> core_getAvailableNetworkInterfaces(); Выходит новое SDK/для новой платформы. Единственное различие со старым - это тот факт, что функция core_getAvailableNetworkInterfaces(); стала асинхронной . В корне не верный подход, более того даже губительный. Новый асинхронный метод должен быть GetAvailableNetworkInterfacesAsync. Думаю не нужно пояснять причину подобного домостроя. МСУ, ты вообще о чем?? " Новый асинхронный метод должен " - кому он должен?? Это метод SDK, ну прибавь к нему Async - что изменится? О чем вопрос - понятно? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:23 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueМСУ, ты вообще о чем?? О том, что добавление нового функционала в API должно быть строго формализовано и реализовано. В частности это достигается введением перегруженных методов или новых. Monochromatique" Новый асинхронный метод должен " - кому он должен?? Тому, кто его использует, вестимо. MonochromatiqueЭто метод SDK, ну прибавь к нему Async - что изменится? Как минимум MSIL. А что? MonochromatiqueО чем вопрос - понятно? Понятно. А тебе? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:27 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
AntonariyАлексей Кпропущено... Никак. Надо сразу делать асинхронным.Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным. Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности. Нет. Вопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной. Если с самого начала этого не предполагалось. Как переделывать по минимуму? Какая архитектура/подход в этом может помочь? При проектировании интерфейсов высокого уровня - надо ли "заморачиваться" на реализацию низкоуровневых функций? Как гарантировано не заморачиваться? И пока вопрос вокруг - можно ли сделать синхронным ставший вдруг асинхронный метод. В таком вот ключе. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:29 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueAntonariyпропущено... Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным. Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности. Нет. Вопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной. Если с самого начала этого не предполагалось. Как переделывать по минимуму? Какая архитектура/подход в этом может помочь? При проектировании интерфейсов высокого уровня - надо ли "заморачиваться" на реализацию низкоуровневых функций? Как гарантировано не заморачиваться? И пока вопрос вокруг - можно ли сделать синхронным ставший вдруг асинхронный метод. В таком вот ключе.Чушь какая-то. Я понимаю, был метод синхронный, добавился асинхронный аналог, но чтобы исчез старый? Из "ядра"? Разработчика ядра в этом случае следует выгнать взашей. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:32 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МСУ, давай еще раз (надеюсь последний). Есть приложение - состоит из модулей, которые: 1. Разрабатывались разными людьми. 2. Соединяются MEF-ом. Всё работает. Меняется функция SDK, становится асинхронной. Я описал пример про получение NW-интерфейсов. Хочется! Переписать только сборку, которая содержит только класс с методом получения списка NW интерфейсов. Заменить её и всё. Всё должно продолжить работать также как и раньше. Это реально? Вопрос про асинхронность ТОЛЬКО В ЭТОМ . Не про названия методов, не про формализцию. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:36 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
AntonariyMonochromatiqueпропущено... Нет. Вопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной. Если с самого начала этого не предполагалось. Как переделывать по минимуму? Какая архитектура/подход в этом может помочь? При проектировании интерфейсов высокого уровня - надо ли "заморачиваться" на реализацию низкоуровневых функций? Как гарантировано не заморачиваться? И пока вопрос вокруг - можно ли сделать синхронным ставший вдруг асинхронный метод. В таком вот ключе.Чушь какая-то. Я понимаю, был метод синхронный, добавился асинхронный аналог, но чтобы исчез старый? Из "ядра"? Разработчика ядра в этом случае следует выгнать взашей. Ну ребят, на вас не угодишь. Более абстрактных примеров вы не понимаете. Конкретные вам не нравятся. Вы, парни, писали что-нибудь кроме SPA? Детские рассуждения какие-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:39 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueМСУ, давай еще раз (надеюсь последний). Ну давай. MonochromatiqueЕсть приложение - состоит из модулей, которые: 1. Разрабатывались разными людьми. 2. Соединяются MEF-ом. Ок. MonochromatiqueВсё работает. Меняется функция SDK, становится асинхронной. Я описал пример про получение NW-интерфейсов. Стоп, дальше даже читать не буду. Мне нужно тебе 10 раз повторить, что нельзя так делать? Monochromatique Хочется! Аргумент не катит. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:46 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МCУСтоп, дальше даже читать не буду. Мне нужно тебе 10 раз повторить, что нельзя так делать? Неужели так сложно вообразить, что может быть ситуация, в которой на положение вещей повлиять нельзя? Смена версии SDK, смена платформы вообще - да мало ли причин?? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:53 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueНеужели так сложно вообразить, что может быть ситуация, в которой на положение вещей повлиять нельзя? Ты же сам просил бэст практик, а теперь начинаешь вилять "а если, а вдруг, если бы да кабы, ...". MonochromatiqueСмена версии SDK, смена платформы вообще - да мало ли причин?? Если тебе интересует не бест практики, а говнопрактики , ну хорошо - заменили в лоб метод на асинковый. Что дальше? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 11:04 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
У меня у одного складывается впечатление, что многоуважаемый Monochromatique ебёт нам моск? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 11:04 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
AntonariyАлексей Кпропущено... Никак. Надо сразу делать асинхронным.Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным. Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности.Ну наверное не цикл, а ожидание WaitHandle, но это сведёт на нет все усилия. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 11:29 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueВопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной.Сказали же - никак. Добавляй новый метод по факту, как предложил МСУ, или сразу планируй интерфейс в расчёте на асинхронность. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 11:32 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МСУУ меня у одного складывается впечатление, что многоуважаемый Monochromatique ебёт нам моск? не только нам, но и себе что характерно ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 11:51 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Изопропилне только нам, но и себе что характерно Ну так на кол его тогда? Иначе как вдолбить в моск человека, что абстракция сама должна "намекать", что метод должен быть асинхронный Код: c# 1. 2. 3. 4.
И добавление нового функционала не должно затирать предыдущую реализацию. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 11:56 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueИ допустим пишу функцию, которая обращается к нативной библиотеке платформы (iOS,Ведро,Винда). Допустим, получает список каких-то ресурсов. Пока всё ровно, пишу три класса, которые реализуют требуемый интерфейс, но типа по разному - платформа то нативная.Чтоб предметно: Код: 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.
MonochromatiqueНо вот в чем закавыка - допустим на винде получение списка ресурсов асинхронное , а на всех остальных - синхронное. Получается, интерфейс для всех реализаций должен подразумевать асинхронную природу? Или как-то это можно обойти (не понимаю как).Один из вариантов -- ориентироваться на "общий знаменатель" -- т.е. на тот функционал, который поддерживается всеми платформами. В твоем конкретном случае можно расчитывать на то, что все платформы умеют получать список ресурсов синхронно, так что Windows-реализацию нужно будет принудительно делать таковой. Другой вариант -- вот так (псевдокод): Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
И потом (тоже псевдокод): Код: c# 1. 2. 3. 4.
MonochromatiqueНо какая же тут слабая связанность, когда реализация нижнего уровня впрямую влияет на реализацию более верхнего?Любая абстракция рано или поздно протекает ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:14 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МСУИзопропилне только нам, но и себе что характерно Ну так на кол его тогда? Иначе как вдолбить в моск человека, что абстракция сама должна "намекать", что метод должен быть асинхронный Код: c# 1. 2. 3. 4.
И добавление нового функционала не должно затирать предыдущую реализацию. Воу-воу, МСУ, палехче. Эти вопросы рождены необходимостью правильно разделять работу между программистами. Отойти от подхода "дали-мяч-*уячь". Сейчас приложения строятся несколько стихийно и не могут выйти за рамки "код-контролировать-может-один/два-человека". Вернуться к приложению годичной давности вообще несколько сложновато. Несколько. Поэтому хочется строить их в соответствии с лучшими практиками, чтобы набить поменьше шишек. Принцип DI, а также и событийно-ориентированная архитектура кажутся наиболее близкими по сути и подходящими подходами. Я пытаюсь сейчас нащупать границы, чтобы не свалиться в абсурд или попасть в ситуацию, когда то, что должно помогать - станет проблемой. Вот и всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:29 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
НахлобучОдин из вариантов -- ориентироваться на "общий знаменатель" -- т.е. на тот функционал, который поддерживается всеми платформами. В твоем конкретном случае можно расчитывать на то, что все платформы умеют получать список ресурсов синхронно , так что Windows-реализацию нужно будет принудительно делать таковой.Если не страшно отказываться от преимуществ асинхронной реализации, а то и вовсе можно нарваться на мёртвую блокировку при определённых условиях. Асинхронность поди не зря в том API добавили. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:29 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Нахлобуч, ай, спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:30 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueСейчас приложения строятся несколько стихийно и не могут выйти за рамки "код-контролировать-может-один/два-человека". Вернуться к приложению годичной давности вообще несколько сложновато.DI и асинхронности не способствуют читабельности кода. Скорее наоборот... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:31 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueНахлобуч, ай, спасибо.Скомпилируй сначала пример Нахлобуча, перед тем как благодарить. Есть сомнения... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:32 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КMonochromatiqueНахлобуч, ай, спасибо.Скомпилируй сначала пример Нахлобуча, перед тем как благодарить. Есть сомнения...Предлагает одно, пишет другое... ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:33 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Я поблагодарил за то, что человек по теме высказался. На скуле это типа редкость! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:34 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КMonochromatiqueСейчас приложения строятся несколько стихийно и не могут выйти за рамки "код-контролировать-может-один/два-человека". Вернуться к приложению годичной давности вообще несколько сложновато.DI и асинхронности не способствуют читабельности кода. Скорее наоборот... Тоже понятно. Но. Упор на то, что каждый "читает" свой кусок. Ну а если неофит какой вдруг решит "окинуть" взглядом всё приложение в целом, то... Я себе это вообще с трудом представляю. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:36 |
|
|
start [/forum/topic.php?fid=20&msg=38443105&tid=1403785]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
79ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 352ms |
total: | 525ms |
0 / 0 |