powered by simpleCommunicator - 2.0.56     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Страсти по DI (IoC).
66 сообщений из 66, показаны все 3 страниц
Страсти по DI (IoC).
    #38441828
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вопрос такой - до какой степени принято (если тут это уместно), делать приложение "слабосвязанным"? Где та грань, показатель "достаточно"?

Ведь в стремлении к декомпозиции можно дойти до "один метод - один класс". А потом уже собирать всё каким-нибудь NINJECT-ом.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38441945
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueГде та грань, показатель "достаточно"?
здравый смысл
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38441950
Фотография Antonariy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилMonochromatiqueГде та грань, показатель "достаточно"?
здравый смысл+ много
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442118
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Общение между слоями и достаточно.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442184
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ,

Слоев может быть много. И разных. Далеко не обязательно ограничиваться DAL,BL и UI. Тот же BL может быть разбит на 15 слоев, которые тоже можно абстрагировать друг от друга.

Никто так не делает?

o_O

Тесты, взаимозаменяемость сборка на лету и прочее....
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442190
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И вопрос вдогонку.

Как бы попроще... Вот допустим, делаю я мобильное приложение на каком-нибудь движке типа Ксамарин.

И допустим пишу функцию, которая обращается к нативной библиотеке платформы (iOS,Ведро,Винда).

Допустим, получает список каких-то ресурсов.

Пока всё ровно, пишу три класса, которые реализуют требуемый интерфейс, но типа по разному - платформа то нативная.

Но вот в чем закавыка - допустим на винде получение списка ресурсов асинхронное , а на всех остальных - синхронное. Получается, интерфейс для всех реализаций должен подразумевать асинхронную природу? Или как-то это можно обойти (не понимаю как).

Но какая же тут слабая связанность, когда реализация нижнего уровня впрямую влияет на реализацию более верхнего?

P.S. Ксамарин приведен для примера. Как-то коробит, что если ты на каком-то низком уровне встречаешь асинхронный метод, то надо переделывать всех, кто пользуется его результатами.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442211
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Monochromatique,
Ваш пример более чем надуманный, должны же перед проектированием приниматься меры для стандартизации кода в разрезе
на каких ос будет использоваться код.
Возвращает асинхронный метод, может лучше результат работы асинхронного метода.
зы Страсти по DI (IoC) - да это тривиальное представление способа исполнения, что его так возвеличивают, на прицепляли
всяких рюшечек: слежение за жизнью, пулов - короновали в фреймворк....
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442388
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueВопрос такой - до какой степени принято (если тут это уместно), делать приложение "слабосвязанным"? Где та грань, показатель "достаточно"?

Ведь в стремлении к декомпозиции можно дойти до "один метод - один класс". А потом уже собирать всё каким-нибудь NINJECT-ом.

эта определённая грань существует. это границы вашего контроля над кодом.

сама природа DI подразумевает инверсию абстракции. в отличие от классического подхода, где нижние слои ничего не знают о верхнем слое, здесь верхние слои ничего не знает о нижних слоях. в этом и проявляется слабая связность компонентов.

поясню. нижний слой реализует некий интерфейс, который использует верхний слой. в таком случае, необходимо знать, что это за интерфейс. возможно это будет дополнительная сборка — хранилище интерфейсов.

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

резюмирую ответ на вопрос. до такой степени, чтобы это было уместно :) как уже сказали выше, по логическим слоям приложения. в принятии решения должно участвовать здравое разумение о тестировании и взаимозаменяемости компонентов. там, где это не нужно, DI не нужен.

1. тестируемость. если функциональность компонента детерминирована (отсутствуют какие-либо побочные эффекты, оказываемые на работу приложения) — DI не нужен.
2. взаимозаменяемость. если имеются предположения о возможной замене реализации конкретного слоя, или подмене реализации при изменении условий — DI нужен.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442631
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueМСУ, Слоев может быть много. И разных. Далеко не обязательно ограничиваться DAL,BL и UI. Тот же BL может быть разбит на 15 слоев, которые тоже можно абстрагировать друг от друга.

1. Если ты не ограничиваешься "стандартными" слоями, это не значит, что им не нужна слабосвязность.
2. BL ты не можешь разбить на 15 слоев, ибо это будет простая декомпозиция. А речь именно о слоях.
3. Тебя интересует теория? К чему эта дискуссия о бесконечной инверсии? Ты и только ты решаешь, что и как расслаивать, что и как декомпозировать, что и как инжектировать. Серебряная пуля лишь у стреляющего.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442762
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, можно определение "слоя"?

3. Мне неизвестны входные данные для принятия решения. Иными словами - best practices. Если они есть. Вот товарищи говорят - насколько дури хватит (чтобы самому не запутаться в коде). Может быть что то еще?

И про асинхронность никто не ответил. Пока очевидный выход такой - изначально подразумевать асинхронность, даже если её нет и вероятно не будет.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442816
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Monochromatique,

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

вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов? люди говорят, насколько дури хватит, может что-то ещё??
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442822
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueИ про асинхронность никто не ответил.

я так и не понял при чём тут асинхронность и DI.

если будете использовать механизм конечных автоматов (async/await) введённых в .NET 4.5, задача упрощается. посмотрите, например, на реализацию Entity Framework 6, большая часть функций имеет асинхронные аналоги (в том числе и для PLINQ). если вы делаете универсальную библиотеку для широкого пользования, то уместно будет поступить также. а для своего приложения, делайте асинк там, где он требуется или может потребоваться. и не делайте, если не нужен и не потребуется. в чём проблема?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442831
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов?"

И в чем проблема-то?

"как лучше всего строить дома?"
Зависит от региона.

"сколько этажей?"
Ограниченно бюджетом, регламентами конкретного региона и возможностями конкретного места.

"сколько комнат?"
Наибольшую ликвидность имеют однухи. Опять же - зависит от региона.

"лифтов?"
Принято 4 лифта на парадную на 100 квартир. Интерполировать сможет и третьеклассник.

Смотри, я ответил на все ваши вопросы, но вы не в состоянии ответить на мои.

Может просто вам кажется , что вы в теме? Бывает и такое.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442835
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

Я просил ОПРЕДЕЛЕНИЕ слоя, а не картинку.

Вы понимаете разницу между:
"На какие слои принято делить приложение"
и
"Приведите определение слоя"

?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442840
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttMonochromatiqueИ про асинхронность никто не ответил.

я так и не понял при чём тут асинхронность и DI.



На самом деле связать и их можно, но в контексте данного топика - я не знаю, зачем вы пытаетесь их связать вместе.

Ок, если вам это сложно вообразить, как могут асинхронные методы резолвиться via DI - забудьте.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442858
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я поясню еще раз, для тех, кто не знает, сколько в квартире должно быть санузлов.

Пишется приложение. Один язык, разные платформы.
Допустим в ходе приложения нужно получить список сетевых интерфейсов.

Один программист создает следующий интерфейс:

IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces();

И программист его реализует и всё работает. Реализует через функцию SDK

IEnumerable<NetworkInterfaceInfo> core_getAvailableNetworkInterfaces();

Выходит новое SDK/для новой платформы. Единственное различие со старым - это тот факт, что функция

core_getAvailableNetworkInterfaces(); стала асинхронной .

То есть, теперь у пользователей на руках две платформы.

Вопросы:
1. Можно ли переписать только реализацию
IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces();
оставив нетронутой остальную часть приложения? Как это сделать?

Варианты ответов:
1. Можно, надо сделать так-то.. (Например замыкания?)
2. Нет, надо переписывать и сам интерфейс, добавлять события и прочее..
3. Надо изначально добавлять асинхронность там, где это возможно.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442887
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueЯ поясню еще раз, для тех, кто не знает, сколько в квартире должно быть санузлов.Никто не знает, сколько в моей квартире должно быть санузлов, даже Вы :)

MonochromatiqueВарианты ответов:
1. Можно, надо сделать так-то.. (Например замыкания?)
2. Нет, надо переписывать и сам интерфейс, добавлять события и прочее..
3. Надо изначально добавлять асинхронность там, где это возможно.Любой вариант может оказаться правильным в моем проекте.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442899
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LRMonochromatiqueЯ поясню еще раз, для тех, кто не знает, сколько в квартире должно быть санузлов.Никто не знает, сколько в моей квартире должно быть санузлов, даже Вы :)

MonochromatiqueВарианты ответов:
1. Можно, надо сделать так-то.. (Например замыкания?)
2. Нет, надо переписывать и сам интерфейс, добавлять события и прочее..
3. Надо изначально добавлять асинхронность там, где это возможно.Любой вариант может оказаться правильным в моем проекте.

В вашей квартире должно быть 0<x<=2. Ответ? Количество клозетов в вашей квартире не попадает в это условие?

Про асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442921
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueВ вашей квартире должно быть 0<x<=2. Ответ? Количество клозетов в вашей квартире не попадает в это условие?Ответ банально прост: жена (еще) не определилась, сколько должно быть :) Т.е. в моем случае вопрос этот более политический, чем технический.

MonochromatiqueПро асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?Ну давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442924
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вдогонку, самый простенький пример, чтобы сразу стало понятно - Observing an Asynchronous Operation
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442958
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueПро асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?Никак. Надо сразу делать асинхронным.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442960
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt1. тестируемость. если функциональность компонента детерминирована (отсутствуют какие-либо побочные эффекты, оказываемые на работу приложения) — DI не нужен.
2. взаимозаменяемость. если имеются предположения о возможной замене реализации конкретного слоя, или подмене реализации при изменении условий — DI нужен.3. Раздельная компиляция (плагиностроение) - нужен.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38442961
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LRНу давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.Зачем нужно "почти", если есть стандартное TPL.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443055
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueМСУ, можно определение "слоя"?
Рассуждаешь о слоях и не понимаешь определения? Отлично! Гугли.

Monochromatique3. Мне неизвестны входные данные для принятия решения. Иными словами - best practices. Если они есть. Вот товарищи говорят - насколько дури хватит (чтобы самому не запутаться в коде). Может быть что то еще?
Про инверсию хорошо написано в application architecture гайде. Кури. Будет твоим best practices.

MonochromatiqueИ про асинхронность никто не ответил. Пока очевидный выход такой - изначально подразумевать асинхронность, даже если её нет и вероятно не будет.
А она тут каким боком?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443061
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueОдин программист создает следующий интерфейс:

IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces();

И программист его реализует и всё работает. Реализует через функцию SDK

IEnumerable<NetworkInterfaceInfo> core_getAvailableNetworkInterfaces();

Выходит новое SDK/для новой платформы. Единственное различие со старым - это тот факт, что функция

core_getAvailableNetworkInterfaces(); стала асинхронной .

В корне не верный подход, более того даже губительный. Новый асинхронный метод должен быть GetAvailableNetworkInterfacesAsync. Думаю не нужно пояснять причину подобного домостроя.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443062
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КLRНу давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.Зачем нужно "почти", если есть стандартное TPL.
+1
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443072
Фотография Antonariy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КMonochromatiqueПро асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?Никак. Надо сразу делать асинхронным.Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным.

Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443077
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУMonochromatiqueОдин программист создает следующий интерфейс:

IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces();

И программист его реализует и всё работает. Реализует через функцию SDK

IEnumerable<NetworkInterfaceInfo> core_getAvailableNetworkInterfaces();

Выходит новое SDK/для новой платформы. Единственное различие со старым - это тот факт, что функция

core_getAvailableNetworkInterfaces(); стала асинхронной .

В корне не верный подход, более того даже губительный. Новый асинхронный метод должен быть GetAvailableNetworkInterfacesAsync. Думаю не нужно пояснять причину подобного домостроя.

МСУ, ты вообще о чем?? " Новый асинхронный метод должен " - кому он должен?? Это метод SDK, ну прибавь к нему Async - что изменится?

О чем вопрос - понятно?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443079
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueМСУ, ты вообще о чем??
О том, что добавление нового функционала в API должно быть строго формализовано и реализовано. В частности это достигается введением перегруженных методов или новых.

Monochromatique" Новый асинхронный метод должен " - кому он должен??
Тому, кто его использует, вестимо.

MonochromatiqueЭто метод SDK, ну прибавь к нему Async - что изменится?
Как минимум MSIL. А что?

MonochromatiqueО чем вопрос - понятно?
Понятно. А тебе?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443082
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AntonariyАлексей Кпропущено...
Никак. Надо сразу делать асинхронным.Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным.

Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности.

Нет. Вопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной. Если с самого начала этого не предполагалось. Как переделывать по минимуму?
Какая архитектура/подход в этом может помочь? При проектировании интерфейсов высокого уровня - надо ли "заморачиваться" на реализацию низкоуровневых функций? Как гарантировано не заморачиваться?

И пока вопрос вокруг - можно ли сделать синхронным ставший вдруг асинхронный метод.

В таком вот ключе.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443083
Фотография Antonariy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueAntonariyпропущено...
Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным.

Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности.

Нет. Вопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной. Если с самого начала этого не предполагалось. Как переделывать по минимуму?
Какая архитектура/подход в этом может помочь? При проектировании интерфейсов высокого уровня - надо ли "заморачиваться" на реализацию низкоуровневых функций? Как гарантировано не заморачиваться?

И пока вопрос вокруг - можно ли сделать синхронным ставший вдруг асинхронный метод.

В таком вот ключе.Чушь какая-то. Я понимаю, был метод синхронный, добавился асинхронный аналог, но чтобы исчез старый? Из "ядра"? Разработчика ядра в этом случае следует выгнать взашей.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443086
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУ, давай еще раз (надеюсь последний).

Есть приложение - состоит из модулей, которые:
1. Разрабатывались разными людьми.
2. Соединяются MEF-ом.

Всё работает. Меняется функция SDK, становится асинхронной. Я описал пример про получение NW-интерфейсов.

Хочется!

Переписать только сборку, которая содержит только класс с методом получения списка NW интерфейсов.

Заменить её и всё. Всё должно продолжить работать также как и раньше.

Это реально? Вопрос про асинхронность ТОЛЬКО В ЭТОМ . Не про названия методов, не про формализцию.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443091
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AntonariyMonochromatiqueпропущено...


Нет. Вопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной. Если с самого начала этого не предполагалось. Как переделывать по минимуму?
Какая архитектура/подход в этом может помочь? При проектировании интерфейсов высокого уровня - надо ли "заморачиваться" на реализацию низкоуровневых функций? Как гарантировано не заморачиваться?

И пока вопрос вокруг - можно ли сделать синхронным ставший вдруг асинхронный метод.

В таком вот ключе.Чушь какая-то. Я понимаю, был метод синхронный, добавился асинхронный аналог, но чтобы исчез старый? Из "ядра"? Разработчика ядра в этом случае следует выгнать взашей.

Ну ребят, на вас не угодишь. Более абстрактных примеров вы не понимаете. Конкретные вам не нравятся.

Вы, парни, писали что-нибудь кроме SPA? Детские рассуждения какие-то.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443099
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueМСУ, давай еще раз (надеюсь последний).
Ну давай.

MonochromatiqueЕсть приложение - состоит из модулей, которые:
1. Разрабатывались разными людьми.
2. Соединяются MEF-ом.
Ок.

MonochromatiqueВсё работает. Меняется функция SDK, становится асинхронной. Я описал пример про получение NW-интерфейсов.
Стоп, дальше даже читать не буду. Мне нужно тебе 10 раз повторить, что нельзя так делать?

Monochromatique Хочется!
Аргумент не катит.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443105
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МCУСтоп, дальше даже читать не буду. Мне нужно тебе 10 раз повторить, что нельзя так делать?

Неужели так сложно вообразить, что может быть ситуация, в которой на положение вещей повлиять нельзя?

Смена версии SDK, смена платформы вообще - да мало ли причин??
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443118
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueНеужели так сложно вообразить, что может быть ситуация, в которой на положение вещей повлиять нельзя?
Ты же сам просил бэст практик, а теперь начинаешь вилять "а если, а вдруг, если бы да кабы, ...".

MonochromatiqueСмена версии SDK, смена платформы вообще - да мало ли причин??
Если тебе интересует не бест практики, а говнопрактики , ну хорошо - заменили в лоб метод на асинковый. Что дальше?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443120
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня у одного складывается впечатление, что многоуважаемый Monochromatique ебёт нам моск?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443151
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
AntonariyАлексей Кпропущено...
Никак. Надо сразу делать асинхронным.Наверное ты прочитал невнимательно. Метод изначально асинхронный, нужно сделать синхронным.

Можно, запустив после вызова цикл, в котором проверяется состояние объекта. Но это ведет к падению производительности.Ну наверное не цикл, а ожидание WaitHandle, но это сведёт на нет все усилия.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443154
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueВопрос о том, как защититься от того, что где-то в недрах ядра какая-то функция стала асинхронной.Сказали же - никак. Добавляй новый метод по факту, как предложил МСУ, или сразу планируй интерфейс в расчёте на асинхронность.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443185
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУУ меня у одного складывается впечатление, что многоуважаемый Monochromatique ебёт нам моск?
не только нам, но и себе что характерно
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443199
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилне только нам, но и себе что характерно
Ну так на кол его тогда?

Иначе как вдолбить в моск человека, что абстракция сама должна "намекать", что метод должен быть асинхронный

Код: c#
1.
2.
3.
4.
public interface IService
{
    Task<T> GetDataAsync();
}



И добавление нового функционала не должно затирать предыдущую реализацию.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443238
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
interface IResourceProvider
{
    IEnumerable<Resource> GetResources();
}

class WindowsResourceProvider : IResourceProvider
{
    public IEnumerable<Resource> GetResources()
    {
        return NativeMethods.GetResources();            
    }    
}

class AndroidResourceProvider : IResourceProvider
{
    public IEnumerable<Resource> GetResources()
    {
        return FactoryProviderFactory.getInstance().getFactory().getProvider().execute(new GetResourcesCommandImpl());
    }    
}

class IOSResourceProvider : IResourceProvider
{
    public IEnumerable<Resource> GetResources()
    {
        return NSResourceManager.getResourcesWithKeyAndValueByLoadingResourceFromXibFileAndReturningErrorOnFailure();
    }    
}



MonochromatiqueНо вот в чем закавыка - допустим на винде получение списка ресурсов асинхронное , а на всех остальных - синхронное. Получается, интерфейс для всех реализаций должен подразумевать асинхронную природу? Или как-то это можно обойти (не понимаю как).Один из вариантов -- ориентироваться на "общий знаменатель" -- т.е. на тот функционал, который поддерживается всеми платформами. В твоем конкретном случае можно расчитывать на то, что все платформы умеют получать список ресурсов синхронно, так что Windows-реализацию нужно будет принудительно делать таковой.

Другой вариант -- вот так (псевдокод):
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
interface IAsyncResourceProvider : IResourceProvider
{
    async IEnumerable<Resource> GetResourcesAsync();    
}

class WindowsResourceProvider : IAsyncResourceProvider
{
    public IEnumerable<Resource> GetResources()
    {
        return NativeMethods.GetResources();            
    }

    public async IEnumerable<Resource> GetResourcesAsync()
    {
        return NativeMethods.GetResourcesAsync();            
    }
}



И потом (тоже псевдокод):
Код: c#
1.
2.
3.
4.
var resourceProvider = ServiceLocator.Resolve<IResourceProvider>();
var resources = resourceProvider is IAsyncResourceProvider ?
    await ((IAsyncResourceProvider)resourceProvider).GetResourcesAsync() :
    resourceProvider.GetResources();



MonochromatiqueНо какая же тут слабая связанность, когда реализация нижнего уровня впрямую влияет на реализацию более верхнего?Любая абстракция рано или поздно протекает
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443263
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МСУИзопропилне только нам, но и себе что характерно
Ну так на кол его тогда?

Иначе как вдолбить в моск человека, что абстракция сама должна "намекать", что метод должен быть асинхронный

Код: c#
1.
2.
3.
4.
public interface IService
{
    Task<T> GetDataAsync();
}



И добавление нового функционала не должно затирать предыдущую реализацию.

Воу-воу, МСУ, палехче.

Эти вопросы рождены необходимостью правильно разделять работу между программистами. Отойти от подхода "дали-мяч-*уячь".
Сейчас приложения строятся несколько стихийно и не могут выйти за рамки "код-контролировать-может-один/два-человека".
Вернуться к приложению годичной давности вообще несколько сложновато. Несколько.

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

Я пытаюсь сейчас нащупать границы, чтобы не свалиться в абсурд или попасть в ситуацию, когда то, что должно помогать - станет проблемой.

Вот и всё.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443264
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучОдин из вариантов -- ориентироваться на "общий знаменатель" -- т.е. на тот функционал, который поддерживается всеми платформами. В твоем конкретном случае можно расчитывать на то, что все платформы умеют получать список ресурсов синхронно , так что Windows-реализацию нужно будет принудительно делать таковой.Если не страшно отказываться от преимуществ асинхронной реализации, а то и вовсе можно нарваться на мёртвую блокировку при определённых условиях. Асинхронность поди не зря в том API добавили.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443266
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нахлобуч,

ай, спасибо.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443269
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueСейчас приложения строятся несколько стихийно и не могут выйти за рамки "код-контролировать-может-один/два-человека".
Вернуться к приложению годичной давности вообще несколько сложновато.DI и асинхронности не способствуют читабельности кода. Скорее наоборот...
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443270
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueНахлобуч,

ай, спасибо.Скомпилируй сначала пример Нахлобуча, перед тем как благодарить. Есть сомнения...
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443272
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КMonochromatiqueНахлобуч,

ай, спасибо.Скомпилируй сначала пример Нахлобуча, перед тем как благодарить. Есть сомнения...Предлагает одно, пишет другое...
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443276
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я поблагодарил за то, что человек по теме высказался. На скуле это типа редкость!
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443285
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КMonochromatiqueСейчас приложения строятся несколько стихийно и не могут выйти за рамки "код-контролировать-может-один/два-человека".
Вернуться к приложению годичной давности вообще несколько сложновато.DI и асинхронности не способствуют читабельности кода. Скорее наоборот...

Тоже понятно. Но. Упор на то, что каждый "читает" свой кусок. Ну а если неофит какой вдруг решит "окинуть" взглядом всё приложение в целом, то... Я себе это вообще с трудом представляю.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443286
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueЯ поблагодарил за то, что человек по теме высказался. На скуле это типа редкость!Неожиданно... Всё остальное по-твоему офтоп? Читай внимательнее.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443288
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueАлексей Кпропущено...
DI и асинхронности не способствуют читабельности кода. Скорее наоборот...

Тоже понятно. Но. Упор на то, что каждый "читает" свой кусок. Ну а если неофит какой вдруг решит "окинуть" взглядом всё приложение в целом, то... Я себе это вообще с трудом представляю.Тупо разбить всё на классы нынче не модно?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443292
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КАлексей Кпропущено...
Скомпилируй сначала пример Нахлобуча, перед тем как благодарить. Есть сомнения...Предлагает одно, пишет другое...Во-первых, я написал, что это -- псевдокод.

Во-вторых, ты о чем?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443300
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КMonochromatiqueпропущено...


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

Так а смысл топика с самого начала об этом. Насколько разбивать всё по классам. И как следствие применения DI - inject-ировать всё в друг-друга.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443303
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучАлексей Кпропущено...
Предлагает одно, пишет другое...Во-первых, я написал, что это -- псевдокод.
Во-вторых, ты о чем?
НахлобучВ твоем конкретном случае можно расчитывать на то, что все платформы умеют получать список ресурсов синхронно , так что Windows-реализацию нужно будет принудительно делать таковой.
И тут же предлагаешь использовать асинхронное продолжение через await:
Нахлобуч
Код: c#
1.
2.
3.
4.
var resourceProvider = ServiceLocator.Resolve<IResourceProvider>();
var resources = resourceProvider is IAsyncResourceProvider ?
    await ((IAsyncResourceProvider)resourceProvider).GetResourcesAsync() :
    resourceProvider.GetResources();

Надеюсь это опечатка?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443306
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КLRНу давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.Зачем нужно "почти", если есть стандартное TPL.
И то верно, Monochromatique, посмотрите пример Using ContinueWith for the Callback Functionality , может это и будет для Вас решением (допустим, "GetFileStringAsync" изначально "GetFileStringSync")
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443308
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MonochromatiqueНасколько разбивать всё по классам.Истина как всегда где-то посередине.
MonochromatiqueИ как следствие применения DI - inject-ировать всё в друг-друга.Как только надоест инжектировать вручную. Кстати, для этого необязательно использовать интерфейсы.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443309
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КИ тут же предлагаешь использовать асинхронное продолжение через await:
Нахлобуч
Код: c#
1.
2.
3.
4.
var resourceProvider = ServiceLocator.Resolve<IResourceProvider>();
var resources = resourceProvider is IAsyncResourceProvider ?
    await ((IAsyncResourceProvider)resourceProvider).GetResourcesAsync() :
    resourceProvider.GetResources();

Надеюсь это опечатка?
Там же сказано: "Другой вариант".

Идея в том, что в клиентском коде динамически опрашиваешь реализации на предмет того, умеют ли они делать что-то нестандартное.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443324
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати. В одной книге видел пример, когда используют MEF и NINJECT вместе. А зачем, разве MEF не покрывает функциональность NINJECT как DI?
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443325
Monochromatique
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...в смысле - как контейнер.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443327
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучТам же сказано: "Другой вариант".Ок.
НахлобучИдея в том, что в клиентском коде динамически опрашиваешь реализации на предмет того, умеют ли они делать что-то нестандартное.В итоге клиент строится исходя из асинхронной реализации. Проще интерфейс сразу сделать асинхронным. Вроде как логика автоматически заменится полиморфизмом. В клиенте не будет лишних if (resourceProvider is IAsyncResourceProvider) { } .
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443370
Фотография Нахлобуч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КВ итоге клиент строится исходя из асинхронной реализации.Не сказал бы. Скорее так: клиент в рантайме выбирает подходящую реализацию, а уж что он там с ней делает -- не дело реализации.

Алексей КПроще интерфейс сразу сделать асинхронным.Я бы не стал; получится "Square peg in a round hole".

Как вариант решения -- в рантайме же оборачивать синхронные реализации в специальную "обертку":
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
class AsyncResourceProviderThunk : IAsyncResourceProvider
{
    private readonly IResourceProvider resourceProvider;

    public async IEnumerable<Resource> GetResourcesAsync()
    {
        return MakeAsync(() => resourceProvider.GetResources());
    }
}
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443442
Фотография Алексей К
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
НахлобучАлексей КВ итоге клиент строится исходя из асинхронной реализации.Не сказал бы. Скорее так: клиент в рантайме выбирает подходящую реализацию, а уж что он там с ней делает -- не дело реализации.Если вызываемый метод асинхронный, все вызывающие методы, вероятно, автоматически станут асинхронными. Это не всегда, но часто. Код или синхронный, или асинхронный. Нельзя быть "наполовину беременным".
НахлобучАлексей КПроще интерфейс сразу сделать асинхронным.Я бы не стал; получится "Square peg in a round hole".Это вынужденная мера.
НахлобучКак вариант решения -- в рантайме же оборачивать синхронные реализации в специальную "обертку":
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
class AsyncResourceProviderThunk : IAsyncResourceProvider
{
    private readonly IResourceProvider resourceProvider;

    public async IEnumerable<Resource> GetResourcesAsync()
    {
        return MakeAsync(() => resourceProvider.GetResources());
    }
}

Ну да, что-то типа того:
Код: c#
1.
2.
3.
4.
5.
6.
7.
class SyncResourceImpl : IAsyncInterface
{
    public Task<Resource> GetResourceAsync()
    {
        return TaskHelper.FromValue(NativeSyncImpl.GetResource());
    }
}
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443507
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей К[/src]Ну да, что-то типа того:
Код: c#
1.
2.
3.
4.
5.
6.
7.
class SyncResourceImpl : IAsyncInterface
{
    public Task<Resource> GetResourceAsync()
    {
        return TaskHelper.FromValue(NativeSyncImpl.GetResource());
    }
}

[/quot]
+1, так и нужно писать.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443510
Фотография МСУ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Алексей КНу да, что-то типа того:
Код: c#
1.
2.
3.
4.
5.
6.
7.
class SyncResourceImpl : IAsyncInterface
{
    public Task<Resource> GetResourceAsync()
    {
        return TaskHelper.FromValue(NativeSyncImpl.GetResource());
    }
}


+1, так и нужно писать.
...
Рейтинг: 0 / 0
Страсти по DI (IoC).
    #38443640
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Monochromatique "вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов?"

И в чем проблема-то?

"как лучше всего строить дома?"
Зависит от региона.

"сколько этажей?"
Ограниченно бюджетом, регламентами конкретного региона и возможностями конкретного места.

"сколько комнат?"
Наибольшую ликвидность имеют однухи. Опять же - зависит от региона.

"лифтов?"
Принято 4 лифта на парадную на 100 квартир. Интерполировать сможет и третьеклассник.

Смотри, я ответил на все ваши вопросы, но вы не в состоянии ответить на мои.

Может просто вам кажется , что вы в теме? Бывает и такое.

ок. делайте 13 слоёв. и не больше 21-го зависимого класса. точно вам говорю, это бест практикс!
...
Рейтинг: 0 / 0
66 сообщений из 66, показаны все 3 страниц
Форумы / WinForms, .Net Framework [игнор отключен] [закрыт для гостей] / Страсти по DI (IoC).
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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