Набросал три примера: goo.gl/MikZq7
Первый - обновление через события - самый неправильный.
Второй - с использованием IMultiValueConverter - лучше.
Третий - с IMultiValueConverter и использованием паттерна MVVM - самый православный.
Я не вижу никаких подводных камней. По сути, при добавлении референса на COM-библиотеку студия генерирует interop-сборку. Нет никаких строгих правил, где должны быть расположены COM-интерфейсы - в подключаемой сборке или в вашей.
Я на самом деле давно не занимался веб-разработкой. Для ликбеза, не подскажете способы? Если я правильно понял автора вопроса, сервисом пользуются обычные люди с обычными браузерами без всяких плагинов для спуффинга.
На самом деле, я думаю, ListBox подойдёт при любом количестве сообщений. Вопрос скорее в реализации нижележащего ItemsSource-а. Скажем, если использовать обычную ObservableCollection, все сообщения придётся хранить в памяти. С 1000 сообщений я погорячился, пожалуй - это не так уж много с точки зрения рахода памяти. В общем, наверно не стоит заниматься преждевременной оптимизацией. Лучше сначала провести эксперимент с ObservableCollection и проверить, на каких значениях начинаются тормоза и чрезмерный расход памяти.
Как уже было сказано, нужно минимизировать число вызовов Dispatcher.Invoke. Второй вариант - использовать Dispatcher.BeginInvoke с приоритетом ниже Input (например, Background). Тогдавсе обращения будут складываться в очередь и выполняться асинхронно, не блокируя рендеринг и пользовательские действия.
Правильно - это почитать книжку по теории графов или погуглить готовое решение (коих миллионы - задача классическая). За вас тут зачёт сдавать никто не будет.
Перечитайте еще раз, пожалуйста. Слово "набор" в моём сообщении означает "Set" в терминах Computer Science. Алгоритмическая сложность поиска в HashSet - O(1). Если иметь HashSet хэш-кодов строк из второго файла в памяти, то можно за O(n) пробежаться по строкам первого файла и найти хэш-коды этих строк в Set-е хэшей второго файла.
А что значит "связать окно с кодом"? =) Не работает Binding? Вам нужно правильно указать DataContext у окна. На сколько я вижу, Вы его вообще не присваиваете. В принципе, можно нагородить костыли с {Binding ElementName=...} или чем-то подобным, но если хотите сделать хорошо, советую почитать про MVVM-паттерн. Вам придётся создать класс с вью-моделью (скорее всего, еще и имплементировать INotifyPropertyChanged), который будет отражать модель данных, отображаемую на форме. А потом надо будет присвоить DataContext-у формы экземпляр этого класса.
cthulhudx: Я не аналитик, никакую статистику не подводил, поэтому всё, что я пишу - это моё личное мнение, которое может быть ошибочным. Но мне кажется, что мир Enterprise не замкнут на самом себе, и выбор технологий отталкивается от принимающих решение сотрудников (системных архитекторов), которые, в свою очередь, отталкиваются во многом от популярности технологий. Я уже сказал, что на данный момент Java всё еще вне конкуренции в этом секторе, но в будущем, на мой взгляд, ситуация будет постепенно меняться. Она уже меняется, на самом деле: язык Java и вправду застоялся на месте; Scala - слишком молодой язык; .Net выходит в open source, что увеличит комьюнити, и, как следствие, количество новых библиотек, фреймворков, и в целом позитивно скажется на популяризации платформы. А в банках, между прочим, тоже любят использовать open source библиотеки. Ну и самое главное - расширение поддержки .net-а на nix-ы. Оно и раньше было через Mono, но это всё не то, "не энтерпрайзно" - до продакшена такое редко допускают.
cthulhudx: Я думаю, тут имеет место психологический фактор. В моей команде примерно 15 java- и 7 C#-разработчиков. И когда разговор заходит о поддержке свойств на уровне языка, подавляющее большинство java-программистов утверждает (и вполне обоснованно), что свойства - это всего лишь синтаксический сахар. Им удобнее и понятнее работать с get/set-методами - по их мнению так улучшается читаемость кода, и, если честно, мне нечем возразить - читаемость и вправду лучше. По поводу индексаторов - тот же аргумент. А Вам нравится переопределение операторов в C#? Уж сколько копий сломлено по поводу того, что эта фича нужна исключительно в узкоспециализированных сферах и часто используется неправильно. То же и про индексаторы - нередко их втыкают туда, где им не место быть.
C#, безусловно, более гибкий язык с точки зрения синтаксиса, но это является как достоинством, так и недостатком. Язык D, например, гораздо более гибкий, чем C++, но это не пошло ему на пользу (по крайней мере, пока).
cthulhudx: Судя по тому, что Вы написали, Вы вполне компетентны сами ответить на свой вопрос. Зачем Вы его задавали, если честно? Для самоутверждения? Ради флейма? Хотите оценить квалификацию аудитории? Или, может, были другие причины? В любом случае, похоже, вы выбрали не тот ресурс.
beduin01: Я Вас умоляю... Джава не умрёт ещё очень долгое время. А зарплаты у java-программистов как были, так и остаются в ~1.2 раза больше C#-программерских, и этот тренд будет оставаться еще очень долго, до тех пор пока .NET полностью не отвоюет юниксовый рынок, что будет нескоро, учитывая временнУю задержку в миграции бизнеса на новые платформы. По предыдущиму опыту долгой смерти Delphi, я бы ставил на 10-15 лет медленного умирания Java. При этом, зарплаты специалистов будут до последнего сохраняться на высоком уровне, поскольку отток специалистов будет компенсировать спрос со стороны клиентов, вынужденных поддерживать устаревшие системы. До сих пор вижу вакансии на Delphi-программистов с достаточно неплохой зарплатой.
P.S. Несмотря на то, что последние 5 лет я работаю C#-программистом, я длительное время проработал Java-программистом в сфере investment banking, где писал как server-side, так и UI. Про UI всем и так всё понятно - Java тут аутсайдер. Про server-side - Java пока держится молодцом. Но эта тенденция сохранялась до тех пор, пока MS не решили выпустить стек .net в open source. Паритет нарушен в пользу Microsoft. У Oracle нет козырей.
Это тоже не совсем корректный вариант. Правильно так:
var handler = StateChanged;
if (handler != null)
{
handler();
}
Причина - многопоточность. В вашем коде проверка StateChanged != null может вернуть true, а потом перед вызовом события последний обработчик возьмёт да и отпишется из другого потока. Тогда StateChanged уже будет равен null, и вызов приведет к NullReferenceException.
Такой огород - это стандарт, которого нужно придерживаться всегда, независимо от того, пишете ли вы однопоточное или многопоточное приложение. Никогда нельзя знать наверняка, во что эволюционирует ваш код. Кстати, в C# 6.0 эту проблему обещают решить. Благодаря поддержке Null-Conditional Operator-ов, можно будет просто написать: StateChanged?.Invoke();
