|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Вопрос такой - до какой степени принято (если тут это уместно), делать приложение "слабосвязанным"? Где та грань, показатель "достаточно"? Ведь в стремлении к декомпозиции можно дойти до "один метод - один класс". А потом уже собирать всё каким-нибудь NINJECT-ом. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2013, 19:33 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueГде та грань, показатель "достаточно"? здравый смысл ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2013, 22:43 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
ИзопропилMonochromatiqueГде та грань, показатель "достаточно"? здравый смысл+ много ... |
|||
:
Нравится:
Не нравится:
|
|||
25.10.2013, 22:48 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Общение между слоями и достаточно. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2013, 10:08 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МСУ, Слоев может быть много. И разных. Далеко не обязательно ограничиваться DAL,BL и UI. Тот же BL может быть разбит на 15 слоев, которые тоже можно абстрагировать друг от друга. Никто так не делает? o_O Тесты, взаимозаменяемость сборка на лету и прочее.... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2013, 12:57 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
И вопрос вдогонку. Как бы попроще... Вот допустим, делаю я мобильное приложение на каком-нибудь движке типа Ксамарин. И допустим пишу функцию, которая обращается к нативной библиотеке платформы (iOS,Ведро,Винда). Допустим, получает список каких-то ресурсов. Пока всё ровно, пишу три класса, которые реализуют требуемый интерфейс, но типа по разному - платформа то нативная. Но вот в чем закавыка - допустим на винде получение списка ресурсов асинхронное , а на всех остальных - синхронное. Получается, интерфейс для всех реализаций должен подразумевать асинхронную природу? Или как-то это можно обойти (не понимаю как). Но какая же тут слабая связанность, когда реализация нижнего уровня впрямую влияет на реализацию более верхнего? P.S. Ксамарин приведен для примера. Как-то коробит, что если ты на каком-то низком уровне встречаешь асинхронный метод, то надо переделывать всех, кто пользуется его результатами. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2013, 13:08 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Monochromatique, Ваш пример более чем надуманный, должны же перед проектированием приниматься меры для стандартизации кода в разрезе на каких ос будет использоваться код. Возвращает асинхронный метод, может лучше результат работы асинхронного метода. зы Страсти по DI (IoC) - да это тривиальное представление способа исполнения, что его так возвеличивают, на прицепляли всяких рюшечек: слежение за жизнью, пулов - короновали в фреймворк.... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2013, 14:53 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueВопрос такой - до какой степени принято (если тут это уместно), делать приложение "слабосвязанным"? Где та грань, показатель "достаточно"? Ведь в стремлении к декомпозиции можно дойти до "один метод - один класс". А потом уже собирать всё каким-нибудь NINJECT-ом. эта определённая грань существует. это границы вашего контроля над кодом. сама природа DI подразумевает инверсию абстракции. в отличие от классического подхода, где нижние слои ничего не знают о верхнем слое, здесь верхние слои ничего не знает о нижних слоях. в этом и проявляется слабая связность компонентов. поясню. нижний слой реализует некий интерфейс, который использует верхний слой. в таком случае, необходимо знать, что это за интерфейс. возможно это будет дополнительная сборка — хранилище интерфейсов. в итоге, слабая связность выливается в дополнительный кодинг. ещё одним минусом является, что при очень слабой связности может быть достаточно трудно разобраться, что же от чего в итоге зависит, и как это всё работает. резюмирую ответ на вопрос. до такой степени, чтобы это было уместно :) как уже сказали выше, по логическим слоям приложения. в принятии решения должно участвовать здравое разумение о тестировании и взаимозаменяемости компонентов. там, где это не нужно, DI не нужен. 1. тестируемость. если функциональность компонента детерминирована (отсутствуют какие-либо побочные эффекты, оказываемые на работу приложения) — DI не нужен. 2. взаимозаменяемость. если имеются предположения о возможной замене реализации конкретного слоя, или подмене реализации при изменении условий — DI нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.10.2013, 23:27 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueМСУ, Слоев может быть много. И разных. Далеко не обязательно ограничиваться DAL,BL и UI. Тот же BL может быть разбит на 15 слоев, которые тоже можно абстрагировать друг от друга. 1. Если ты не ограничиваешься "стандартными" слоями, это не значит, что им не нужна слабосвязность. 2. BL ты не можешь разбить на 15 слоев, ибо это будет простая декомпозиция. А речь именно о слоях. 3. Тебя интересует теория? К чему эта дискуссия о бесконечной инверсии? Ты и только ты решаешь, что и как расслаивать, что и как декомпозировать, что и как инжектировать. Серебряная пуля лишь у стреляющего. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 17:47 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
МСУ, можно определение "слоя"? 3. Мне неизвестны входные данные для принятия решения. Иными словами - best practices. Если они есть. Вот товарищи говорят - насколько дури хватит (чтобы самому не запутаться в коде). Может быть что то еще? И про асинхронность никто не ответил. Пока очевидный выход такой - изначально подразумевать асинхронность, даже если её нет и вероятно не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 22:13 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Monochromatique, про слои легко гуглится, литературы достаточно. бест практики бест практикам рознь. без конкретной задачи и конкретных условий, ваш вопрос вообще лишён какого-либо смысла. вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов? люди говорят, насколько дури хватит, может что-то ещё?? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 23:23 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueИ про асинхронность никто не ответил. я так и не понял при чём тут асинхронность и DI. если будете использовать механизм конечных автоматов (async/await) введённых в .NET 4.5, задача упрощается. посмотрите, например, на реализацию Entity Framework 6, большая часть функций имеет асинхронные аналоги (в том числе и для PLINQ). если вы делаете универсальную библиотеку для широкого пользования, то уместно будет поступить также. а для своего приложения, делайте асинк там, где он требуется или может потребоваться. и не делайте, если не нужен и не потребуется. в чём проблема? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 23:36 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
"вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов?" И в чем проблема-то? "как лучше всего строить дома?" Зависит от региона. "сколько этажей?" Ограниченно бюджетом, регламентами конкретного региона и возможностями конкретного места. "сколько комнат?" Наибольшую ликвидность имеют однухи. Опять же - зависит от региона. "лифтов?" Принято 4 лифта на парадную на 100 квартир. Интерполировать сможет и третьеклассник. Смотри, я ответил на все ваши вопросы, но вы не в состоянии ответить на мои. Может просто вам кажется , что вы в теме? Бывает и такое. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 23:44 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
hVostt, Я просил ОПРЕДЕЛЕНИЕ слоя, а не картинку. Вы понимаете разницу между: "На какие слои принято делить приложение" и "Приведите определение слоя" ? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 23:46 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
hVosttMonochromatiqueИ про асинхронность никто не ответил. я так и не понял при чём тут асинхронность и DI. На самом деле связать и их можно, но в контексте данного топика - я не знаю, зачем вы пытаетесь их связать вместе. Ок, если вам это сложно вообразить, как могут асинхронные методы резолвиться via DI - забудьте. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2013, 23:52 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Я поясню еще раз, для тех, кто не знает, сколько в квартире должно быть санузлов. Пишется приложение. Один язык, разные платформы. Допустим в ходе приложения нужно получить список сетевых интерфейсов. Один программист создает следующий интерфейс: IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces(); И программист его реализует и всё работает. Реализует через функцию SDK IEnumerable<NetworkInterfaceInfo> core_getAvailableNetworkInterfaces(); Выходит новое SDK/для новой платформы. Единственное различие со старым - это тот факт, что функция core_getAvailableNetworkInterfaces(); стала асинхронной . То есть, теперь у пользователей на руках две платформы. Вопросы: 1. Можно ли переписать только реализацию IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces(); оставив нетронутой остальную часть приложения? Как это сделать? Варианты ответов: 1. Можно, надо сделать так-то.. (Например замыкания?) 2. Нет, надо переписывать и сам интерфейс, добавлять события и прочее.. 3. Надо изначально добавлять асинхронность там, где это возможно. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 00:09 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueЯ поясню еще раз, для тех, кто не знает, сколько в квартире должно быть санузлов.Никто не знает, сколько в моей квартире должно быть санузлов, даже Вы :) MonochromatiqueВарианты ответов: 1. Можно, надо сделать так-то.. (Например замыкания?) 2. Нет, надо переписывать и сам интерфейс, добавлять события и прочее.. 3. Надо изначально добавлять асинхронность там, где это возможно.Любой вариант может оказаться правильным в моем проекте. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 00:30 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
LRMonochromatiqueЯ поясню еще раз, для тех, кто не знает, сколько в квартире должно быть санузлов.Никто не знает, сколько в моей квартире должно быть санузлов, даже Вы :) MonochromatiqueВарианты ответов: 1. Можно, надо сделать так-то.. (Например замыкания?) 2. Нет, надо переписывать и сам интерфейс, добавлять события и прочее.. 3. Надо изначально добавлять асинхронность там, где это возможно.Любой вариант может оказаться правильным в моем проекте. В вашей квартире должно быть 0<x<=2. Ответ? Количество клозетов в вашей квартире не попадает в это условие? Про асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 00:47 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueВ вашей квартире должно быть 0<x<=2. Ответ? Количество клозетов в вашей квартире не попадает в это условие?Ответ банально прост: жена (еще) не определилась, сколько должно быть :) Т.е. в моем случае вопрос этот более политический, чем технический. MonochromatiqueПро асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?Ну давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 01:27 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Вдогонку, самый простенький пример, чтобы сразу стало понятно - Observing an Asynchronous Operation ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 01:34 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueПро асинхронность сведу к простому - возможно ли работу асинхронного метода завернуть в синхронную обертку? Если возможно, то как?Никак. Надо сразу делать асинхронным. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 06:04 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
hVostt1. тестируемость. если функциональность компонента детерминирована (отсутствуют какие-либо побочные эффекты, оказываемые на работу приложения) — DI не нужен. 2. взаимозаменяемость. если имеются предположения о возможной замене реализации конкретного слоя, или подмене реализации при изменении условий — DI нужен.3. Раздельная компиляция (плагиностроение) - нужен. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 06:07 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
LRНу давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.Зачем нужно "почти", если есть стандартное TPL. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 06:09 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueМСУ, можно определение "слоя"? Рассуждаешь о слоях и не понимаешь определения? Отлично! Гугли. Monochromatique3. Мне неизвестны входные данные для принятия решения. Иными словами - best practices. Если они есть. Вот товарищи говорят - насколько дури хватит (чтобы самому не запутаться в коде). Может быть что то еще? Про инверсию хорошо написано в application architecture гайде. Кури. Будет твоим best practices. MonochromatiqueИ про асинхронность никто не ответил. Пока очевидный выход такой - изначально подразумевать асинхронность, даже если её нет и вероятно не будет. А она тут каким боком? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:04 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueОдин программист создает следующий интерфейс: IEnumerable<NetworkInterfaceInfo> iGetAvailableNetworkInterfaces(); И программист его реализует и всё работает. Реализует через функцию SDK IEnumerable<NetworkInterfaceInfo> core_getAvailableNetworkInterfaces(); Выходит новое SDK/для новой платформы. Единственное различие со старым - это тот факт, что функция core_getAvailableNetworkInterfaces(); стала асинхронной . В корне не верный подход, более того даже губительный. Новый асинхронный метод должен быть GetAvailableNetworkInterfacesAsync. Думаю не нужно пояснять причину подобного домостроя. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 10:06 |
|
Страсти по 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 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueЯ поблагодарил за то, что человек по теме высказался. На скуле это типа редкость!Неожиданно... Всё остальное по-твоему офтоп? Читай внимательнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:36 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueАлексей Кпропущено... DI и асинхронности не способствуют читабельности кода. Скорее наоборот... Тоже понятно. Но. Упор на то, что каждый "читает" свой кусок. Ну а если неофит какой вдруг решит "окинуть" взглядом всё приложение в целом, то... Я себе это вообще с трудом представляю.Тупо разбить всё на классы нынче не модно? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:37 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КАлексей Кпропущено... Скомпилируй сначала пример Нахлобуча, перед тем как благодарить. Есть сомнения...Предлагает одно, пишет другое...Во-первых, я написал, что это -- псевдокод. Во-вторых, ты о чем? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:38 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КMonochromatiqueпропущено... Тоже понятно. Но. Упор на то, что каждый "читает" свой кусок. Ну а если неофит какой вдруг решит "окинуть" взглядом всё приложение в целом, то... Я себе это вообще с трудом представляю.Тупо разбить всё на классы нынче не модно? Так а смысл топика с самого начала об этом. Насколько разбивать всё по классам. И как следствие применения DI - inject-ировать всё в друг-друга. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:40 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
НахлобучАлексей Кпропущено... Предлагает одно, пишет другое...Во-первых, я написал, что это -- псевдокод. Во-вторых, ты о чем? НахлобучВ твоем конкретном случае можно расчитывать на то, что все платформы умеют получать список ресурсов синхронно , так что Windows-реализацию нужно будет принудительно делать таковой. И тут же предлагаешь использовать асинхронное продолжение через await: Нахлобуч Код: c# 1. 2. 3. 4.
Надеюсь это опечатка? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:41 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КLRНу давно уже существует "почти стандартное" средство Rx (Reactive Extensions) ( msdn ), на форуме часто упоминалось.Зачем нужно "почти", если есть стандартное TPL. И то верно, Monochromatique, посмотрите пример Using ContinueWith for the Callback Functionality , может это и будет для Вас решением (допустим, "GetFileStringAsync" изначально "GetFileStringSync") ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:42 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
MonochromatiqueНасколько разбивать всё по классам.Истина как всегда где-то посередине. MonochromatiqueИ как следствие применения DI - inject-ировать всё в друг-друга.Как только надоест инжектировать вручную. Кстати, для этого необязательно использовать интерфейсы. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:43 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КИ тут же предлагаешь использовать асинхронное продолжение через await: Нахлобуч Код: c# 1. 2. 3. 4.
Надеюсь это опечатка? Там же сказано: "Другой вариант". Идея в том, что в клиентском коде динамически опрашиваешь реализации на предмет того, умеют ли они делать что-то нестандартное. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:44 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Кстати. В одной книге видел пример, когда используют MEF и NINJECT вместе. А зачем, разве MEF не покрывает функциональность NINJECT как DI? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:49 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
...в смысле - как контейнер. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:50 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
НахлобучТам же сказано: "Другой вариант".Ок. НахлобучИдея в том, что в клиентском коде динамически опрашиваешь реализации на предмет того, умеют ли они делать что-то нестандартное.В итоге клиент строится исходя из асинхронной реализации. Проще интерфейс сразу сделать асинхронным. Вроде как логика автоматически заменится полиморфизмом. В клиенте не будет лишних if (resourceProvider is IAsyncResourceProvider) { } . ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 12:51 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КВ итоге клиент строится исходя из асинхронной реализации.Не сказал бы. Скорее так: клиент в рантайме выбирает подходящую реализацию, а уж что он там с ней делает -- не дело реализации. Алексей КПроще интерфейс сразу сделать асинхронным.Я бы не стал; получится "Square peg in a round hole". Как вариант решения -- в рантайме же оборачивать синхронные реализации в специальную "обертку": Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 13:12 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
НахлобучАлексей КВ итоге клиент строится исходя из асинхронной реализации.Не сказал бы. Скорее так: клиент в рантайме выбирает подходящую реализацию, а уж что он там с ней делает -- не дело реализации.Если вызываемый метод асинхронный, все вызывающие методы, вероятно, автоматически станут асинхронными. Это не всегда, но часто. Код или синхронный, или асинхронный. Нельзя быть "наполовину беременным". НахлобучАлексей КПроще интерфейс сразу сделать асинхронным.Я бы не стал; получится "Square peg in a round hole".Это вынужденная мера. НахлобучКак вариант решения -- в рантайме же оборачивать синхронные реализации в специальную "обертку": Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9.
Ну да, что-то типа того: Код: c# 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 13:38 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей К[/src]Ну да, что-то типа того: Код: c# 1. 2. 3. 4. 5. 6. 7.
[/quot] +1, так и нужно писать. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 14:14 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Алексей КНу да, что-то типа того: Код: c# 1. 2. 3. 4. 5. 6. 7.
+1, так и нужно писать. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 14:14 |
|
Страсти по DI (IoC).
|
|||
---|---|---|---|
#18+
Monochromatique "вот пример. как лучше всего строить дома? сколько этажей? сколько комнат? лифтов?" И в чем проблема-то? "как лучше всего строить дома?" Зависит от региона. "сколько этажей?" Ограниченно бюджетом, регламентами конкретного региона и возможностями конкретного места. "сколько комнат?" Наибольшую ликвидность имеют однухи. Опять же - зависит от региона. "лифтов?" Принято 4 лифта на парадную на 100 квартир. Интерполировать сможет и третьеклассник. Смотри, я ответил на все ваши вопросы, но вы не в состоянии ответить на мои. Может просто вам кажется , что вы в теме? Бывает и такое. ок. делайте 13 слоёв. и не больше 21-го зависимого класса. точно вам говорю, это бест практикс! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2013, 15:15 |
|
|
start [/forum/topic.php?all=1&fid=20&tid=1403785]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
120ms |
get tp. blocked users: |
1ms |
others: | 326ms |
total: | 563ms |
0 / 0 |