Без пересборки в теории тоже можно - всё ведь зависит от строки подключения. Дал другую строку - подключился к другому месту. Но!
1. Может не оказаться провайдера данных для такого хранилища.
2. Это не значит, что не нужно строить приложение на абстракциях, в частности, обращения к источнику данных.
Нет. Нужно смотреть на сценарии использования, размер, необходимость расширения, наличие наследований в модели данных. Выбор сложнее, чем просто автогенерация. К тому же DB-first болезненнее в поддержке, разработке и миграции данных.
Я понял, почему так сейчас.
1. Строго говоря тема начинается с ForumMessage и не существует отдельно от него. Значит, можно разорвать связь User-Theme полностью и определять владельца темы (зачем?) через первое сообщение или сообщение с флагом, что оно главное для Theme. Как модификация этого варианта в Theme сделать связь с ForumMessage 1 к 1 - "главное сообщение".
2. Сделать связь User-Theme необязательной (для UserId установить тип в int?). Нехорошо, поскольку по факту у темы должен быть владелец, выходит, что вариант компромисный.
@dzedzinskiy
Я, если честно, заинтригован. Что понимать под сбоем при записи? Пока конфигурация не будет сохранена явно, на диск ничего не будет сбрасываться. Исключения при вызове Save приведут только к тому, что новые параметры не будут записаны.
Если речь идёт о жёстком сбое при записи на диск (отключение питания?), как поведут себя внутренности Save тоже неясно. При работе с файлами через потоки я не встречал грязных данных от сбоев и не встречал обработки неполной структуры загруженных данных. Ну, то есть, обработка заключалась в том, что файл невозможно было прочитать и пользователь оповещался о невозможности продолжать работу с приложением.
Я пытался придумать способ для эмуляции "сбоя", но не смог придумать наспех реализации. Поисковики тоже не помогли попыткам найти информацию о жёстких сбоях при работе с конфигурационными файлами.
Я знаю, что если конфиг поправить руками неудачным образом, то приложение будет падать при старте. Но о необходимости дополнительной защиты при записи в конфиг нигде не читал. Скажем так, я заразился паранойей, но подтверждений опасности не нашёл. Где-нибудь есть статьи про проблемы с грязными данными после сбоев во время записи файлов (по факту - сброса буффера на диск)?
@dzedzinskiy да уж, вопрос о том, что хранить в конфиге и что является конфигурацией приложения - неоднозначный в этой ситуации. Мало исходных данных.
Если приводить примеры того, что в конфигах храниться, то вот что получится.
1. Пути к папкам отчётов/выгрузок.
2. Адрес удаленного сервера для подключения.
3. Последнее состояние окна (статус, развернуто ли на весь экран, ширина, высота)! Вот тут уже интересно, данные это или конфигурация?
4. Настройки последней авторизации (логин, флаг авторизации через AD). Это уже что-то похожее на то, что требуется @XuPoH
В общем, я бы не был столь критичен относительно выбора места хранения. Конфигурация понятие довольно растяжимое. lastlogin вполне под неё подходит.
Нет, у нас были десктопные приложения. Смотрел уроки с деплоем в Azure - интересно. Как деплоить на свой стенд не в курсе.
Если менеджмент и наглядная иллюстрация статуса задач не нужны (обходитесь без этого или успешно ведёте в другом месте), то одна из прелестей уходит.
Если есть доступный source control, к которому привыкли (работать вообще без него всегда чревато потерей исходников, что может больно ударить, даже если они потеряются через год-два), это тоже убавит очков VS online. У нас лежат исходники 4 проектов, к которым мы иногда обращаемся за удачными решениями, поэтому иметь доступ к ним всегда и везде удобно.
Если не пишите юнит и интеграционные тесты, то gc тоже даст больше проблем, чем пользы (из-за того, что в cisual studio online иногда проблемы с внешними зависимостями, например Code contracts у меня так и не получилось подключить).
В случае с одним человеком единственным преимуществом будет архив с исходниками проектов в одном месте, но здесь есть более легковесные альтернативы. Тот же приватный репозиторий на github.
Я хотел бы добавить, что wcf очень крутая технология. Которая лучше всего проявляет себя при связи двух .net приложений, сокрывая транспортный уровень. wcf хорош. Он мощен. Но под ваши задачи этой мощи не требуется. И wcf чаще применяется для работы в интранете, он может работать и во внешней сети, но заточен всё-таки больше для работы с локалкой.
Угу, угу, я встречал это в двух реализациях - одна при помощи дуплексного канала с сервером, который при изменении данных в БД клиентам шлёт уведомления. Другая - через Enterprise library cache application block + service broker.
>> shared memory
Нет, серьезно? Какой в этом смысл? Веб-страница может обращаться к web api сервису, который будет пинать внешний TcpListnerService, отдающий всегда актуальную информацию. На странице это сделать хоть по таймеру, а дальше заморачиваться нет смысла. Как будут взаимодействовать TcpListnerService и ApiController уже другое дело - если они в одном домене приложения, то можно обращаться напрямую, если в разных, то через какой-нибудь wcf. Но... но... shared memory....
