WhiteNinja А я правильно понимаю, что Ваша реализация UnitOfWork, в принципе, "дублирует" реализацию EntityFramework, но в тоже время позволяет абстрагироваться от конкретного способа обращения к данным (т.е. можно легко заменить, например, EF на NHibernate или Native SQL)? Я слышал об этом шаблоне, но пока не "взял на вооружение"...
Anton Bormotov у меня много вопросов :) вот смотрите: последний тег пусть будет v1.1.3. А что тогда будет в текущем HEAD? это HEAD ветки master? немного непонятно, что выведет git log между последний тегом и текущим HEAD... И еще вопрос: я правильно понимаю, что tag Вы указываете только при push после merge Вашей ветки develop с веткой master? а при простом commit Вы, получается, тег не указываете?
qqwrst, добрый день! Если я Вас правильно понял, то у Вас все разработчики просто делают commit'ы в определенном формате, потом Вы эти коммиты вытаскиваете и, образно говоря, "кладете" куда-нибудь (в файл, например)?
Дмитрий Ковальский ну да, мой комментарий больше ушел в сторону общего использования null. А что касается данного конкретного вопроса, то я считаю, что в данном методе GetAdresses() при ловле исключения в блоке catch нельзя возвращать ни null, ни Enumerable.Empty. Только throw (вместе с логированием).
Дмитрий Ковальский - не согласен с Вами в том, что всегда лучше возвращать пустой список. Очень часто бизнес-логика бывает такой сложной, что избежать null-объектов почти невозможно. Добавьте сюда еще и ограниченные сроки реализации задач. Разработчику нужно постоянно следить за тем, чтобы не было null-объектов, а по мне - это сущий геморрой. Из личного опыта - гораздо проще обрабатывать null-ситуации (здесь я имею в виду проверку на null, а не обработку NullReferenceException), чем пытаться уйти от null. Все равно никогда от null-ситуаций Вы не уйдете. И проще проверить на null. Тем более, что в C# 6.0 появилась такая замечательная конструкция, как ?.
Кирилл Таран - согласен полностью. Да, Сергей Коновалов, в блоках catch лучше ставить throw. А еще лучше перед throw ставить логирование. Я бы добавил еще про разницу между
Кстати, по поводу переноса проекта, написанного на WebForms, на архитектуру MVC - тут я бы поспорил. Все зависит от размеров проекта и объема костылей в нем. В 90% случаев, на мой взгляд, трудозатраты по переносу проекта с WebForms на MVC невыгодны. Проще уж оставить как есть. Но в каждом случае надо разбираться отдельно. Если заказчик хочет, то почему бы и нет - его же деньги. Но просто так самому переносить проект с WebForms на MVC - я бы даже начинать не стал.
Насчет удобства - тут сложно сказать, что удобнее: WebForms или MVC. Наверное, это тоже субъективно. Лично для меня сам принцип, положенный в основу WebForms неприемлем. Он "загрязняет" код (причем ужасно) - как c# (Господи, кто ж придумал эти события страниц?!), так и html (кастомизация ни к черту). Нормальную архитектуру веб-приложения с EntityFramework и DI не напишешь, тестами не покроешь... А термины "веб сайт" и "веб приложения" у меня вызывают лишь отвращение... Плюс его только в том, что якобы можно быстро набросать эскиз будущего веб приложения. По мне, это очень спорно. Хороший MVC-специалист набросает эскиз также быстро, но при этом код будет прозрачнее и понятнее. Ну, это я отвлекся. Вам, скорее всего, он будет удобен, раз Вы работаете в основном с Grid и Details. Но Вы же не будете всю жизнь делать проекты, в которых используются только Grid'ы и Details'ы, правильно? Сделайте 1 проект на MVC, посмотрите, что Вам больше по душе. Но хочу предупредить: в серьезных enterprise-проектах на WebForms написаны дремучие приложение, которым лет 10 (MVC тогда не было), и которых, наверное, можно по пальцам пересчитать. Все относительно новые и интересные вещи пишутся на MVC, и поэтому без знаний MVC Вам будет сложно найти работу с интересными и большими проектами (и большой базой опыта и знаний соответственно).
Владимир Ионов Добрый день!
4. Похоже, что в Вашем случае простой Razor и впрямь не очень-то подойдет... Мне тоже было бы не в радость тысячи строк JS-кода врукопашную писать. Получается тогда лучше брать связку WebAPI + Angular... MVC-то в Вашем случае особо и не нужен. Хотя я не уверен, что SignalR (realtime web app) работает в связке с WebAPI (сам не пробовал).
5. Сам с гридами не работал, но быстро погуглив - на первый взгляд вот этот грид вроде бы интересный- www.jquery-bootgrid.com
Кстати, Владимир, а какой механизм авторизации Вы используете для проекта? MembershipAPI, Identity or something else? Используете ли ORM-фреймворки? Каким образом у Вас будет осуществляться интеграция с телефонией?
