Про то, что в LOH объекты не сдвигаются, тут есть.
Про LOH информация устарела. GC умеет "дефрагметировать" LOH. https://docs.microsoft.com/en-us/dotnet/api/system.runtime.gcsettings.largeobjectheapcompactionmode?view=net-6.0#System_Runtime_GCSettings_LargeObjectHeapCompactionMode
Всем спасибо за ответы.
Я постарался сократить вопрос (пример) до минимума, чтобы не подводить к варианту, который я поддерживаю в споре с коллегой. Собственно, я за вариант, когда создание Message возлагается на отдельный класс.
Вариант со статикой мне не нравится (код снова останется в менеджере, не получится мокать (Moq)). А вот отдельная фабрика — это гуд!
Решил вот добавить еще одну маленькую деталь, которая добавляет (ИМХО) перевес в сторону инжектабл конвертера(фабрики).
class Manager{
ctro Manager( IProvider provider, IFormatter formatter)
public IEnumerable<Message> GetBy(...) {
return m_provider.GetBy(...).Select(Convert);
}
private Message Convert(DTO) {
string s = m_formatter.ToPlaintext( DTO.Prop3 ); // IText Prop3
return new Message(DTO.Prop1, DTO.Prop2, s);
}
}
class Manager{
ctro Manager( IProvider provider)
public IEnumerable<Message> GetBy(...) {
return m_provider.GetBy(...).Select(Convert);
}
private Message Convert(DTO) {
string s = DTO.Prop3.ToString();
return new Message(DTO.Prop1, DTO.Prop2, s);
}
}
Message «не содержит» поведения.
Правильно ли делать метод Convert приватным в менеджере или стоит заинжектить в конструктор менеджера некий mocable MessageConverter?
Нормально ли использовать new в Convert?
FreeSwitch — это правильно. Жаль мы пока не можем просто переключиться с Астериска на FreeSwitch, но с другой стороны, у нас все работает в связке Sipml5 + Asterisk 11.10 (SDES).
Идея с фреймом сработает.
Мы предупреждаем пользователя сообщением (в случае активного звонка), что он собирается покинуть страницу и поэтому звонок будет завершен (с возможностью отмены действия).
Еще, как вариант, веб телефон можно засунуть в браузерное расширение и тогда такой проблемы вообще не будет.
Из того что я знаю, умельцы все еще в процессе issues.asterisk.org/jira/browse/ASTERISK-22961
О варианте с дополнительным проксированием знаю, но он мне не по душе. Хватит с меня Астериска :)
+1 — sipml5 меня тоже постоянно огорчает. Единственное, почему вынужден использовать его (sipml5) вместо JsSip — перевод звонков. Но как только JsSip поддержит transfer — сразу переведу систему на него (благо все для этого заранее подготовлено).
Выход Chrome 35 заставил патчить sipml, чтобы использовать как и раньше SDES, пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.
Статью пиши обязательно.
PS: размер sipml5 в минифицированом виде ~1 Mb — кошмар!
Спасибо!
У любой медали 2 стороны. То что Вы описали, действительно хорошо, но только тогда, когда необходимо повторное использование и когда кода много настолько, что можно получить спагетти. В противном случае, можно и не вводить к вью и вью модели еще и биндинг хандлер, чтобы не усложнять (по поводу связанности вью и вью модели — вряд ли это так страшно).
Поддерживаю! А еще противоестественно, когда в asp.net проекте, для минификации JS используется Goolge Closure Compiler, который для своей работы требует Java :)
Это зря! MEF и MAF — два разных подхода. MEF не позволяет получить изоляцию (использование AppDomain), а именно это мне и надо и именно это хорошо умеет MAF.
ystem.Addin is a great technology for addressing issues around versioning resliance, isolation and recoverability.
• Using System.Addin allows you to host different components in separate app domains, thus allowing those addins to have different versions of assemblies which they reference which all run in the same process.
• System.Addin allows you to separately version Addins so that you could have two versions of an Addin sitting side by side.
• System.Addin manages automatically unloading app-domains they are no longer used thus allowing you reclaim memory.
• System.Addin has a bunch of security infrastructure (addins run in a sandbox) to ensure that components that are loaded do not have unauthorized access to data in the rest of the app.
• System.AddIn allows your app to gracefully recover whenever one of the addins crashes (this is due to isolation)
MEF on the other hand is a great technology for discovery and composition
• MEF composes deep object hierarchies of components
• MEF abstracts components from static dependencies.
• MEF can allow components to be lazily loaded and lazily instantiated.
• MEF provides a cataloging mechanism and rich metadata for components to allow them to dynamically discovered.
• MEF can compose components from various programming models, it is not bound to static types.
Про LOH информация устарела. GC умеет "дефрагметировать" LOH. https://docs.microsoft.com/en-us/dotnet/api/system.runtime.gcsettings.largeobjectheapcompactionmode?view=net-6.0#System_Runtime_GCSettings_LargeObjectHeapCompactionMode
Я постарался сократить вопрос (пример) до минимума, чтобы не подводить к варианту, который я поддерживаю в споре с коллегой. Собственно, я за вариант, когда создание Message возлагается на отдельный класс.
Вариант со статикой мне не нравится (код снова останется в менеджере, не получится мокать (Moq)). А вот отдельная фабрика — это гуд!
Решил вот добавить еще одну маленькую деталь, которая добавляет (ИМХО) перевес в сторону инжектабл конвертера(фабрики).
Message «не содержит» поведения.
Правильно ли делать метод Convert приватным в менеджере или стоит заинжектить в конструктор менеджера некий mocable MessageConverter?
Нормально ли использовать new в Convert?
Мы предупреждаем пользователя сообщением (в случае активного звонка), что он собирается покинуть страницу и поэтому звонок будет завершен (с возможностью отмены действия).
Еще, как вариант, веб телефон можно засунуть в браузерное расширение и тогда такой проблемы вообще не будет.
О варианте с дополнительным проксированием знаю, но он мне не по душе. Хватит с меня Астериска :)
Выход Chrome 35 заставил патчить sipml, чтобы использовать как и раньше SDES, пока умельцы Астериска не порешают все проблемы с DTLS + WebRTC.
Статью пиши обязательно.
PS: размер sipml5 в минифицированом виде ~1 Mb — кошмар!
У любой медали 2 стороны. То что Вы описали, действительно хорошо, но только тогда, когда необходимо повторное использование и когда кода много настолько, что можно получить спагетти. В противном случае, можно и не вводить к вью и вью модели еще и биндинг хандлер, чтобы не усложнять (по поводу связанности вью и вью модели — вряд ли это так страшно).
Зачем вообще тогда было писать первую статью?
и былое доверие к ФБ утрачено
Это просто смешно! Дыры есть везде!