Станислав Макаров

Для чего нужны виртуальные методы?

Виртуальные методы - это реализация полиморфизма в C++.

Обычная виртуальная функция нужна для правильного вызова перегруженных функций в производных классах

Переопределённых, а не перегруженных.

Но для чего нужен виртуальный деструктор, к примеру?

Объект тоже может разрушаться полиморфно:

class shape {
public:
    virtual ~shape() { } // без virtual будет вызван деструктор класса shape
};

class circle : shape {
public:
     virtual ~shape() { } // c virtual вызовется деструктор именно того класса, объект которого вы разрушаете
....
};

shape* c = new circle();
.....
delete c; // вызов деструктора. С virtual вызовется деструктор circle, а не shape, как нам и надо.

ODP.NET это надстройка над ADO.NET?

Ну у вас и каша в голове, неудивительно, что вы ничего не можете найти.

ADO.NET - это прежде всего набор интерфейсов, обеспечивающих написание кода, работающего с реляционными данными таким образом, что он минимально зависит (или не зависит вообще) от конкретной используемой СУБД. ADO.NET это далеко не первая попытка унифицировать интерфейс доступа к базам данных (хотя бы к реляционным), многие крупные вендоры это делали, тот же Борланд.

С момента появления дотнета как платформы ADO.NET был и остаётся основным способом доступа к реляционным БД из дотнет-приложений. В большинстве случаев нет причин НЕ пользоваться им. Стоит отметить, что хоть сейчас MS советует использовать ORM (с тех пор, как повзрослел Entity Framework) для доступа к данным, ADO.NET никуда не девался, т.к. все известные мне ORM-ми работают также через эти интерфейсы.

Провайдеров данных существует множество, и существование каждого из провайдеров определяется существованием конкретной СУБД. ODP.NET это не надстройка над ADO.NET, это реализация интерфейсов ADO.NET, способная взаимодействовать с Ораклом. Аналогичные провайдеры существуют и для других популярных СУБД, включая PostgreSQL, DB2, MySQL и даже SQLite. По сути доступность реляционной СУБД на дотнете определяется наличием работоспособного ADO.NET-провайдера.

Разумеется, конкретный провайдер может добавлять какой-то специфичный функционал, но при этом он должен реализовать все необходимые интерфейсы. Фишка ADO.NET в том, что реально написать такое приложение (разумеется, если пользоваться только стандартными SQL конструкциями), которое ВООБЩЕ не будет зависеть от конкретной СУБД вплоть до того, что нужного провайдера можно будет указывать в конфиг-файле.

Большинство интерфейсов и классов ADO.NET находятся в пространстве имён System.Data. Условно они делятся на собственно интерфейсы для доступа к БД (важнейшие из них: IDbConnection, IDbCommand, IDataReader) и классы-хелперы, в частности набор классов для организации простейшей in-memory базы данных внутри вашего приложения, которая будет служить кэшем для данных, взятых из основной БД (важнейшие классы: DataSet, DataTable).

Слышал что есть управляемые и неуправляемые провайдеры данных, в чем отличие?

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

Почитать об этом можно в любой нормальной книжке по дотнету. Если остались вопросы, пишите в комментарии.

GEOS конечно, чего тут думать.

• Координата.
  
• Точка: широта+долгота или широта+догота+высота.
  
• Линия: линия соединяющаяя две точки по кратчайшему...
  
• Многоугольник.
  
• Круг. - идеального круга скорее всего нет, т.к. его нет в спецификациях OGC.
  

• Дистанцию между точками, точкой и прямой, многоуго...
  
• Площадь многоугольника, круга...
  
• Проверка принадлежности одного объекта к другому (см. ниже).
  
• Пересечение/объединение/разность объектов.
  
• Прямая/обратная геодезические задачи. - не могу сказать, в геодезии пока не очень, вы имеете в виду преобразование координат?
  

Если не верите мне, поверьте команде PostGIS :)

GEOS for many geometry processing algorithms
Proj.4 for coordinate re-projection functions
GDAL for raster processing and format support

Не совсем понятно, зачем вам это. Когда вы пишете using System.IO в текущий скоуп добавляются сущности из всего System.IO, не важно из какой сборки (иными словами, со всех сборок сразу). В этом и смысл пространств имён в дотнете - они предствляют собой способ логического деления проекта и библиотек (в отличие от физического деления на сборки). Если вы не хотите подключать всё, подключите конкретный класс таким образом:
using StreamReader = System.IO.StreamReader;

interface IFoo
{
  // Не содержит метод Commit()
  // Но содержит все остальные методы и свойства, которые реализованы в классе Foo
}
interface ITransaction
{
    void Commit();
}
class Foo : IFoo, ITransaction
{
  // ...
  
  public void Commit() 
  {
    // ...
  }
}

class Bar<T, TImpl> where TImpl : T, ITransaction, new()
{
  private readonly TImpl _foo;

  protected T Foo {
    get { return _foo; }
  }

  public Bar() {
    _foo = new TImpl();
  }
 
  public void Commit()
  {
    _foo.Commit();
  }
}

А) Залогиньтесь через WebBrowser, возьмите куку, отдайте WebClient-у, скачайте файл;
Б) Разберитесь, как происходит авторизация на сайте, проведите её с помощью WebClient, получите куку, установите её в запрос на скачивание файла, скачайте файл.

В основном — процессы, связанные с устареванием одних технологий (C#, C++, Objective-C, ActionScript, Perl) и появлением их заменителей (JavaScript, Swift, R, Go).

Go заменяет C#, C++ и Perl в одном лице? Можно мы не будем обсуждать этот рейтинг?

По второй ссылке не вижу ничего конкретно про C#. Ну понятно что Джава будет популярнее - MS только начали исправлять ситуацию с псевдокроссплатформенностью C#, отразится это довольно не скоро. Многие метрики учитывают open-source код и открытые данные, а C# язык корпоративный, одному богу известно кто и где на нём сейчас что пишет. Java в общем-то тоже, но проектов в открытом доступе на ней значительно больше.

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

В TypeScript-код невозможно непосредственно подключить JS-файл, т.к. компилятору TypeScript требуется дополнительная информация о том, что находится "внутри" подключаемого модуля. Для того, чтобы сообщить компилятору эту информацию, используются так называемые declaration файлы (с расширением .d.ts). Их обычно кладут рядом с js файлом с таким же именем (в вашем случае это будет parent.d.ts). В таком файле необходимо описать все сущности, экспортирующиеся из соответстующего JS файла. Подробности можно почитать тут.

Разумеется, вам ничего не мешает переписать parent.js на TypeScript, если вам так проще.

Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.

Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?

Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".

включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?

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

Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?

А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.

Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.

Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).

Техническому директору проекта ("архитектору") гораздо важнее уметь правильно обрабатывать информацию, уметь снимать маркетинговую шелуху (вроде той, что была и есть с NoSQL от всех проблем и несчастий), спокойно реагировать на модные баззворды, и собирать библиотеку доверенных людей и информационных ресурсов. И важно знать о вещах, которые с течением времени не меняются, или меняются медленно и неохотно:

• для каких задач подходят функциональные языки, а для каких - ОО;
  
• что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;
  
• что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;
  
• что веб-фреймворки бывают толстые и тонкие;
  
• какие сегодня есть вариации паттерна MVC;
  
• что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;
  
• что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;
  
• что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;
  
• что транзакции в СУБД придумали не для того, чтобы учебники стали толще.
  

При этом "узким горлышком" производительности веб приложений как правило является именно БД.

Логично, ведь большинство веб-приложений это выборка с некоторой простой обработкой. А БД не все умеют хорошо спроектировать.

Имеет ли смысл сортировать и группировать результаты выборки с помощью ЯП, чтобы убрать сортировку и группировку из запросов?

Это имеет смысл только если у вас вообще нет индексов, и по каким-то непостижимым причинам вы не можете их добавить. Чтобы отсортировать быстрее СУБД, нужно построить индекс самому, а вы вряд ли сделаете это лучше СУБД, еще и так, чтобы покрыть расходы на передачу данных. Группировку имеет смысл только если агрегирующая функция вычислительно очень сложная, но такое вы скорее всего в SQL запросе писать и не будете.

Даже если у вас sort и group действительно занимают основной процент времени, перенос этих операций в код приложения врядли вам поможет. Иначе говоря, пока вы добьетесь приемлемого результата от такого решения, вы добрую часть алгоритмов СУБД перепишите заново (сначала вы напишите индексы для поиска или сортировку слиянием, потом, как заметил Сергей Савостин у вас всё равно данные не будут влезать в ОЗУ и вы захотите писать их на диск, тут же вашу копию данных в приложении нужно будет синхронизировать и вы начнёте писать примитивную репликацию и так далее..)

- не надо ли переписать каждый UserControl в свой отдельный проект (.dll) и после этого тягать его в основное окно?

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

- что в общем можно прочитать про корректную архитектуру приложения (насколько я понял, вопрос именно по этой теме)?

Raffaele Garofalo, "Building Enterprise Applicatio...

- хотелось бы начать работать с версиями своего проекта. Visual Studio Team Services вроде как подходит, откуда начать изучение данного сервиса?

Лучше начните с Git. Можно конечно поработать и со Студийным контролем версий, но раз уж вы не работали еще вообще ни с чем, гит будет более универсальным скиллом ввиду его подавляющей популярности. И да, самое главное - вам не обязательно будет сразу пользоваться каким-то сервисом, проект можно версионировать и у себя на машине, и залить в VSTS при необходимости. Удивительно, как вы до сих пор не пользовались никакой VCS, видимо вы аккуратный и терпеливый человек)

Да, убедитесь что вы разобрались с MVVM. Может быть стоит подобрать фреймворк или самому собрать базовую библиотеку, если уже есть наработки.