eRKa

Все зависит от того какими методологиями разработки Вы пользуетесь.

Чаще все это выглядит так:
1) Сначала накидываются пользовательские истории (user story), тот функционал, который Вы хотите иметь в программе. Они состоят из одного-двух предложений, кратко описывают одну единственную функцию. Например: хочу, чтобы была авторизация пользователей с подтверждением по email; хочу, чтобы у пользователя с ролью "админ" была собственная страничка для администрирования; и.д. В историях не должно быть никаких технических нюансов, только "хочу" заказчика (ну или Ваши).

2) Затем составляется карта (roadmap), в которой Вы описываете каждый шаг работы этой функции (пользовательской истории) с точки зрения пользователя:
1. Главная страница.
1.1 В правом верхнем углу находятся поля для аутентификации (для логина и пароля). Рядом находится кнопка "войти" и ссылка "зарегистрироваться".
1.2 При удачной аутентификации происходит переход на страницу ... и выводится сообщение "Добро пожаловать ..."

Потом на основе этой карты, делается прототипирование, выделяются задачи, если надо, разбиваются на более мелкие подзадачи.

Чтоб увидеть чужие ТЗ, полазите по чужому коду на гитхабе. Там очень часто люди описывают свой roadmap.

Чтоб парсить, надо определить какой-то шаблон, как искать и по какому критерию. Тут вариант, усложнять задачу: капчи - для отображения какой то инфы, просите каких то подверждений от клиента. Ломайте теги, где это можно сделать безболезненно, не закрывайте их, реализуйте показ одной и той же инфы разными способами. Вобщем добавте гемора писателям парсеров) Как только заметили, что кто-то парсит - измените страницу по мелочи.

Сериализация и десериализация должны быть в одной сборке. Иначе он не может типы распознать. Поэтому методы по сериализации/десериализации выносят в один проект/dll. Или сериализовать в xml, тогда методы можно разнести по разным сборкам.

Основные моменты описаны постом ваше, но я тоже от себя добавлю.

Если хотите развиваться именно в .net, то и учить надо WPF, ado.net, Entity, asp.net mvc, WCF.

Много читайте, не ограничивайтесь книгами только по С#, есть много всего, без чего не обходится разработка ПО. Это патерны проектирования, процесс разработки, различные инструменты разработки, фреймворки.

Станислав правильно сказал: смотря что называть моделью. Те классы, которые генерит EF, вполне можно называть моделями и даже добавить им логику, может даже какие-то атрибуты. Главное, чтобы все добавки не противоречили тем соответствиям, что EF установил.

В программе куча ошибок. Вы, наверное, слабо представляете, что такое cin/cout раз так их применяете. Совет - почитайте внимательнее учебник, так же обратите внимание на операторы if и for.

Чтобы пройтись по массиву:

for(int i=0; i<1000; i++) { cin >> array[i];  .... }

Чтобы сравнить число:
if(array[i] == 0) { ... }

В Вашей реализации Func1() всегда вернет последнее введенное Вами число. Она не возвращает массив.

Каждый раз вызывая Func2() Вы обнуляете счетчик отрицательных чисел.
int iter = 0 надо убрать из него и вставить в мэйне до первого вызова этой функции. И опять таки, Func2() проверяет не весь массив, а только одно число которое приходит из первой функции, а из первой функции приходит последнее введенной Вами число.
А Func3() выведет Вам тоже самое число, которое вернет Func1(). В таком виде от него вообще смысла нет.

Учите то, в чем есть потребность. 5-я и 6-я версии действительно сильно отличаются. Если начать, то можно и с 6-ой, пока изучите, наэкспериментируетесь, может новые проекты будут уже только на ней и делать.

Проблема в то, что Вы обработку события добавили к label1, а надо было для Form1. Только что проверил, все работает.

private void Form1_KeyDown(object sender, KeyEventArgs e)
        {
            switch (e.KeyCode.ToString())
            {
                case "Down":
                    label1.Top += 45;
                    break;

                case "Up":
                    label1.Top -= 45;
                    break;

                case "Left":
                    label1.Left -= 45;
                    break;

                case "Right":
                    label1.Left += 45;
                    break;
            }
        }
    }

Только не комильфо так писать e.KeyCode.ToString()
Вариант покрасифше)

switch (e.KeyCode)
            {
                case Keys.Down:
                    label1.Top += 45;
                    break;

                case Keys.Up:
                    label1.Top -= 45;
                    break;

                case Keys.Left:
                    label1.Left -= 45;
                    break;

                case Keys.Right:
                    label1.Left += 45;
                    break;
            }

Думаю, что у Вас на форме нет поля для Tags. Если вводить данные вручную для Tags на форме не надо , то сделайте его скрытым, но проинициализируйте теми данными, которые Вы захотите получить при получении данных с формы.

Тоже подозрение, что COUNTRY_ID не свойство.

Я бы добавил Setting файл (ссылку на работу с файлом параметров Вам постом выше оставили), в который добавил бы необходимые параметры для запуска приложения. При начале работы приложения брал бы данные от туда. Когда эти параметры будут меняться в процессе работы, их сохранять в этом файле. И каким бы образом приложение ни закрылось, текущее состояние будет сохранено в сеттинге.

У меня точно такой же вопрос стоит уже вторую неделю, только в другом контексте. Мониторинг GPS трекеров. Есть серверная часть, которая по UDP протоколу получает сообщение от трекера и которая так же имеет доступ к БД, чтоб понять кому принадлежит трекер, затем сообщение уходит на хаб SignalR для отсылки веб-клиенту. Получается что у меня два конекшина к базе, от сервера с сайтом (ASP.NET MVC) и от сервера с хабом. И тоже думаю как сделать одно соединение, чтоб базу меньше напрягать, и тоже кручусь вокруг WCF или Web API.

Это устаревший пример. Этим патерном уже навряд ли пользуются. Есть готовые ассинхронные методы, которые вызываются через async await. Если Вы конечно с нуля пишите свои методы, то в любом случае применяя async await нет необходимости самому писать callback, компилятор все сделает за Вас.

Я бы выбрал WPF. Много готовых возможностей. Не видел как он выглядит на планшетах, но сенсорные экраны поддерживает. Для дизайна там вообще есть где развернуться.

В WPF я бы сделал такую фишку через слои. На одном слое калькулятор, на другом лабел с автором. При выборе в меню справка/автор, менял бы слой с автором на верхний, при возвращении - возвращал слой с калькулятором вверх.

Мне не удобно. Одно время пришлось с нетбуком кодить. Мне мало того текста, что помещается на экране. Поэтому хорошее кресло, ноги на стол, клаву на руки и два монитора 24" )

Все дело в формате даты. При ее написании нужно учитывать культуру, где вы ее читать будете.

Я бы предпочел json. В последнее время большинство склоняется к его использованию, всетаки для JS он роднее. Даже майкрософты, в некоторых своих продуктах переходят с xml на json.