aol-nnov не согласен насчёт скваша всего и вся. Коммит должен выполнять одно осмысленное изменение. Оно может быть на 1 строчку, может быть на 1000 строк в разных файлах. В идеале он еще не должен ломать проект. Понятно что баги будут, но стоит стремиться не коммитить заведемо неработающий код. Вот как раз в таких случаях squash бывает полезен - слепить проблемный коммит и новый нормальный.
Тут мы плавно переходим к вопросу бисекта. Во-первых скошить всё не стоит потому что проблему с фичей нужно не только констатировать, но еще и чинить. Фичи могут делаться по 2 месяца и коммитов может быть штук 100, и мёржить в мастер это не всегда возможно. Если же после мёржа находится баг, то как раз бисект прекрасно может помочь, особенно если программист который делал фичу ушёл в отпуск (вот очень похожая ситуация была у нас летом). В случае нормальных коммитов, т.е. таких которые а) хотя бы собираются нормально и не ломают абсолютно всё; б) которые вносят осмысленные атомарные изменения; поиск проблемного коммита превращается в полуавтоматическую задачу, и пофиксить возможно получится даже без дебага.
Если сквошить как предлагаете вы, то bisect в смёрженных бранчах бесполезен по определению. Мне кажется это неудачный подход.
> "унифицированные", которые позволяют совершать общие действия, но без специфики БД(ADO.NET)?
нет, не правильно. Вы противопоставляете ADO.NET и ODP.NET, это не верно. ADO.NET это НЕ провайдер, это набор интерфейсов. Конкретный провайдер (например, ODP.NET) реализует эти интерфейсы. Нет "специализированных" и "унифицированных" провайдеров. В теории конечно можно написать провайдер, который работает сразу с несколькими СУБД или просто оборачивает какую-то другую технологию доступа (см. провайдеры OleDb и Odbc), но всё равно это будет реализация ADO.NET интерфейсов.
Ещё раз: ADO.NET это НЕ провайдер, это фреймворк доступа к данным, который, помимо прочего, определяет общие унифицированные ИНТЕРФЕЙСЫ для доступа к данным. ODP.NET это провайдер, реализующий эти интерфейсы, конкретно для работы с Oracle.
Если всё еще непонятно, то приведу аналогию. Есть USB интерфейс, есть какой-нибудь собственный разъём на телефонах какого-нибудь Самсунга. USB-интерфейс - это ADO.NET, собственный разъём на телефоне - это сетевой протокол Оракла (который отличается от сетевого протокола какого-нибудь Постгреса). ODP.NET - это кабель-адаптер, на одном конце которого - USB, на другом - штекер для Самсунговского разъёма. Этот "кабель" позволяет подключить телефон к компьютеру - соединить конкретную СУБД и ваше приложение. Если вам нужна другая СУБД (телефон другого производителя) - вы берёте другой кабель, с одной стороны у которого всё также USB-штекер (ADO.NET-интерфейсы), а с другой - штекер для разъёма другого производителя.
Вы с самим дотнетом-то знакомы? Я рассчитывал что ссылки на MSDN прояснят ситуацию)
Smilleey конечно, некоторые вендоры (да тот же Близзард) имеют свою инфраструктуру развёртывания и установки, включая проверку обновлений, даунлоадеры, патчи и всё остальное, но таким обычно заморачиваются только крупные компании, у которых сотни тысяч установок и куча непростых требований.
Smilleey не совсем понимаю, зачем вести именно разработку во внутренней сети. Во внутреннюю сеть достаточно перенести манифесты и файлы приложения. Правда да, могут потребоваться административные учётки. А как вы вообще разворачиваете приложение без участия администраторов, интересно?) Они хоть не против?))
И да, можно поглядеть и на MSI. Это более замороченный вариант, то такой установщик выложить можно вообще как обычный файл. Но тогда вам в приложении нужно будет самостоятельно выполнять проверку обновлений примерно по той же схеме, что вы предложили с EXE, только всё-таки не EXE, а MSI. Версионировать EXE плохая идея: сейчас вам нужен только он, завтра понадобится версионировать и другие сборки, и в конце концов к установщику вы и придёте. Или потратите на разработку деплоя столько же времени, сколько на само приложение.
> Уровни бизнес логики и доступа к данным
Что конкретно у вас на этих уровнях? Их далеко не всегда разделяют. Какие сервисы и классы где расположены? Сущности и доступ к БД через ADO.NET или орм-ку - на уровне данных?
source2003 вы работали с конкретными СУБД, а не с СУБД "NoSQL" и "SQL". Было бы логично указать, с чем вы работали. Если SQL-базы еще более менее похожи друг на друга, то по термину "NoSQL" вообще непонятно, что вы делали - то ли в Монге хранили JSON-документы, то ли пользовались time-series базами, то ли кэшировали запросы в каком-нибудь Redis. Вот это я вам и хотел сказать. Тут одних key-value СУБД столько уже, что целую таблицу можно составлять, не говоря уже о других базах под грифом "NoSQL"
Если слегка преувеличить, ваш вопрос звучит как "Я пользовался стулом (SQL) и другой мебелью (NoSQL). Почувствовал разницу, но до сих пор не могу понять, когда лучше пользоваться стулом, а когда - прочей мебелью". Слишком уж много всего входит в понятие "прочая мебель".
bogdanstefanjuk Если не собираетесь прямо вот завтра устраиваться на работу, т.е. действительно еще есть время поучиться, учите C#, .NET вообще и .NET Core в частности, а также новый ASP.NET Core. Первые программки можно написать консольными или на WinForms, чтобы не заморачиваться сразу с вебом. Наличие работы проверяется на сайтах вакансий, а также выяснением стека технологий фирм в вашем городе. В моём таких достаточно. Сам C# много где еще можно увидеть, особенно в зрелых коммерческих продуктах, но и ASP.NET должен вновь стать популярным, ибо теперь он будет действительно кроссплатформенным.
При таком вендоре как MS и таких вложениях технология врядли исчезнет в ближайшие лет 10. А на больший срок планировать смысла нет, слишком уж быстро ландшафт меняется, всё равно переучиваться придётся (хотя популярности Джавы можно позавидовать).
Максим Иванов и да, собственно альтернативой EAV и является документаная модель данных и документная СУБД (большинство из них работают с JSON или XML документами).
В ней даётся приемлемое объяснение подхода. ER-модель, ссылку на которую вы привели, это не то, это про другое.
Если собираетесь развиваться в IT, учите английский. К большому сожалению, на данный момент - шаг влево, шаг вправо - и инфы на русском нет. В английской статье на Википедии масса сведений и примеров.
Тут мы плавно переходим к вопросу бисекта. Во-первых скошить всё не стоит потому что проблему с фичей нужно не только констатировать, но еще и чинить. Фичи могут делаться по 2 месяца и коммитов может быть штук 100, и мёржить в мастер это не всегда возможно. Если же после мёржа находится баг, то как раз бисект прекрасно может помочь, особенно если программист который делал фичу ушёл в отпуск (вот очень похожая ситуация была у нас летом). В случае нормальных коммитов, т.е. таких которые а) хотя бы собираются нормально и не ломают абсолютно всё; б) которые вносят осмысленные атомарные изменения; поиск проблемного коммита превращается в полуавтоматическую задачу, и пофиксить возможно получится даже без дебага.
Если сквошить как предлагаете вы, то bisect в смёрженных бранчах бесполезен по определению. Мне кажется это неудачный подход.