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

Использую: .NET (Full + Core) C#, ASP.NET MVC, ASP.NET Core, EntityFramework (6 + Core), Dapper, SQL Server, PostgreSQL, MySQL, Git, IoC/DI, Ajax, jQuery, HTML, CSS, Firebird
Контакты

Достижения

Все достижения (4)

Наибольший вклад в теги

Все теги (29)

Лучшие ответы пользователя

Все ответы (43)
  • Как легче освоить внедрение зависимостей, code-first, TDD и паттерны?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый вечер! Спасибо за приглашение.
    На мой взгляд, Вам следует придерживаться следующих приоритетов по изучению:
    1. внедрение зависимостей более важно из Вашего списка, т.к. относится к SOLID принципам;
    2. TDD - на мой взгляд, вещь более нужная для изучения, чем code-first или patterns. Сам не так давно начал разрабатывать по TDD. Это очень здорово, что изобрели такой подход. Экономит тонну времени на ручное тестирование, а также дает быстрое понимание, что и где случайно (или неслучайно) сломалось. Главное - понимать, что покрывать тестами;
    3. третьим в список я бы добавил AngularJS или KnockoutJS или BackboneJS - сам пока что не изучил их и не начал применять, но судя по их популярности и преимуществам - думаю, Вам стоит с ними ознакомиться;
    4. code-first или database-first - не так уж и важно на Вашем этапе понимания. Главное отличие подхода Code-first: 1) модель пишется вручную, в связи с чем не нужно постоянно отслеживать edmx-диаграмму (т.е. можно считать, что Ваша code-first модель всегда находится в актуальном состоянии); 2) поддерживает миграции БД. В Database-first Вам нужно самому отслеживать актуальность состояния Вашей edmx-модели - с этим тоже могут быть проблемы. Опять же - только с опытом. С другой стороны, Database-first позволяет наглядно видеть Вашу модель, а вот Code-first - нет;
    5. паттернами тоже можете пока что голову не забивать. Безусловно, это нужно, но понимание их придет только с опытом (признаюсь честно: я сам не до конца все паттерны знаю и понимаю). На мой взгляд, важно соблюдать 1 основной паттерн - 3-уровневая архитектура (клиентский слой, слой бизнес-логики, слой работы с данными).

    Теперь по MVC.
    1. Model - тут, в принципе, всё просто: модель данных. Здесь можно поспорить, что иметь в виду под Моделью: модель самих данных или модель представления. Лично я после опыта работы с шаблоном MVVM в WPF под моделью данных в терминах ASP.NET MVC понимаю модель представления, а под термином "модель данных" - саму доменную модель (EF code-first, например). Кто-то может сказать, что это "лишняя работа" - по упаковыванию модели данных из EF-объектов в объекты модели представления. Да, частично соглашусь. Но зато это дает некую гарантию безопасности, что случайно пользователь не поменяет важную часть модели данных (например, ID).
    2. Контроллер. Основная задача контроллера - сформировать данные для отображения и передать эти данные в представление. Т.е. нужно стремиться к тому, чтобы код метода действия в контроллере содержал минимум кода. В идеале - вызов метода из слоя бизнес-логики и передача полученных данных в представление. Если Вы видите, что метод действия в контроллере содержит какую-то бизнес-логику, то это сигнал к рефакторингу: Ваш метод действия слишком много знает. По опыту могу добавить, что в среднем код метода действия содержит от 2 до 20-30 строк кода (с учетом того, что скобки { и } расположены на отдельных строках).
    3. Представление. Тут тоже всё просто: отобразить данные (из модели представления). Ни в коем случае нельзя в представлении писать логику по работе с самими данными, например, так делать нельзя:
    <div id="account">
        @{
            using(var db = new MyEfDbContext()
            {
                var userAccount = db.Accounts.FirstOrDefault(e => e.Username == User.Identity.Username);
                if(userAccount != null)
                {
                    @:Имя: @userAccount.Name
                    @:Фамилия: @userAccount.LastName
                }
            }
        }
    </div>


    Если у Вас 3-уровневая архитектура, например, есть слои:
    1. MyApp.MVC - MVC-application
    2. MyApp.BL - слой бизнес-логики
    3. MyApp.DAL - слой работы с данными
    то в представлении (View) вызывать напрямую сервисы бизнес-логики тоже нельзя, особенно, если Вы используете DI-принцип (внедрение зависимостей) и IoC контейнер. Т.е. такой пример недопустим:
    <div id="account">
        @{
            var accountService = new MyApp.BL.AccountService();
            var userAccount = accountService.GetUserAccountByUsername(User.Identity.Name);
            if(userAccount != null)
            {
                @:Имя: @userAccount.Name
                @:Фамилия: @userAccount.LastName
            }
        }
    </div>

    Попробую донести мысль архитектора и разработчика Александра Шевчука (преподавателя с http://itvdn.com): "Одна из главных целей при разработке - стремиться к упрощению системы". Ослабление зависимостей позволяет нам упрощать систему благодаря тому, что изменение осуществляется только на 1 каком-то слое/уровне. Если Вы во View вынесете логику по работе с данными, а уж тем более, как в примерах выше, работу с EF-контекстом, то Вы усилите зависимость одного компонента системы (MVC-слоя) от другого (слоя работы с данными или слоя бизнес-логики). Усиление зависимостей приводит к бОльшему числу изменений, что в свою очередь сказывается на повышении расходов на эту систему. Ослабление зависимостей приводит к меньшему числу изменений (например, при переходе от EF к native SQL или NHibernate затрагивается только слой работы с данными, а слой MVC и бизнес-логики не меняются), а значит, к более раннему выпуску системы или очередного релиза, и как следствие, снижение расходов (не только денежных, но и других ресурсов) на разработку. TDD тоже можно отнести к практикам, которые снижают затраты ресурсов на содержание системы. Но это я ушел в глобальное...

    Правильным будет подход, при котором у Вас снижается зависимость компонентов системы друг от друга, в случае с ASP.NET MVC приложением, на мой взгляд, это когда:
    - View знает о модели (я по прежнему буду иметь в виду модель представления - ViewModel, которые объявлены либо в MVC-слое, либо в слое бизнес-логики);
    - контроллер знает о слое бизнес-логики, обращается к нему за выполнением операций и получением ViewModel'ей, после чего передает во View полученную ViewModel (ну или JSON-данные);
    - Model формируется по принципу, грубо говоря, почти на каждую View своя модель.

    Фразу "правильным будет подход" я обосновываю тем, что у такого подхода есть масса плюсов (которые очевидны опытным разработчикам, но могут быть не до конца или неправильно поняты менее опытными коллегами, а именно):
    + View ничего не знает о доменной модели (только о ViewModel), благодаря чему Вы можете спокойно менять свою доменную модель, не внося изменений во View (см. выше про ослабление зависимостей и снижение количества связей). Также Вы спокойно можете перейти от EF к NHibernate или к native SQL, или использовать и то, и другое - View об этом никогда не узнает;
    + контроллер (да и весь MVC-слой) знает только о существовании слоя бизнес-логики, но ничего не знает о слое работы с данными.
    + если на View делать отдельную ViewModel, то это позволяет более полноценно управлять тем, что нужно показать пользователю. Т.е. дает возможность большего контроля отображаемых данных, повышает безопасность Вашего приложения (пользователь, например, не сможет изменить ID просматриваемой записи, если этого ID нет вообще в модели представления).

    Ну а вообще все зависит от задачи/проекта: нужно ли применять разбивку на слои или использовать ViewModel'и вместо обычных доменных моделей - надо думать над каждой ситуацией отдельно.

    P.S. На мой взгляд, литературу выбрали правильно - я тоже начинал изучение MVC с нее. Понравилась тем, что дается сначала общее описание и работа с ASP.NET MVC на сквозном примере. А потом идет более глубокое погружение в ASP.NET MVC. По разработке могу посоветовать блог Александра Бындю: blog.byndyu.ru Как мне кажется, там очень хорошо некоторые моменты разжевываются, в том числе SOLID, TDD, шаблон Repository, UnitOfWork и др.
    Ответ написан
  • Какую выбрать технологию и язык для написания диплома (ASP.NET MVC 4 или Yii PHP Framework или Ruby on Rails)?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!
    Вставлю свои 5 копеек по ASP.NET MVC:

    1. Скорость изучения.
    Учитывая, что Вы уже знакомы с C#, то изучение основ ASP.NET и особенностей разработки на ASP.NET MVC с помощью книг "Microsoft ASP .NET 4 с примерами на c# 2010 для профессионалов" (Мэтью МакДональд, Адам Фримен, Марио Шпушта) и "ASP.NET MVC3 (или 4) Framework с примерами на C# для профессионалов" (Адам Фримен, Стивен Сандерсон) займет у Вас примерно месяц при условии 4-5 часов занятий в день.
    Если будете разрабатывать на ASP.NET MVC и выберете ORM EntityFramework, то берите сразу последнюю (6.1.) версию. Статья по EF6 Вам в помощь.

    2. Функциональность.
    Этого пункта не понял, поэтому лучше промолчу.

    3. Создание api (или через что лучше организовать доступ с сайту через мобильное приложение?) для приложения андроид.
    На asp.net есть отличные статьи по ASP.NET WebAPI.

    4. Возможность найти помощь по проблемам (другими словами размер лояльного сообщества)
    К Вашим услугам:
    MSDN
    asp.net
    Stackoverflow
    Собственно, сам Toster и Хабр
    Лично я обычно делаю так: захожу в гугл и формирую запрос по английски, потому что по личному опыту, так решить проблему можно быстрее, чем искать на русскоязычных источниках.

    5. Сложность изучения
    Опять-таки учитывая тот факт, что с C# Вы уже знакомы, то - примерно средняя (чисто субъективно).

    6. Производительность
    Боюсь, тут я ничем Вам не смогу помочь, т.к. на PHP/RoR я не программировал и производительность всех трех технологий не сравнивал. Что касательно MVC, то заметил, что на локальном ПК (localhost) при разработке веб-приложение грузится чуть медленнее, чем на реальном хостинге или выделенном сервере (Да оно, собственно говоря, и понятно, т.к. на хостинге-то стоит нормальный IIS, а в VisualStudio при build проекта он запускается под Local IIS Express)

    7. Подскажите что еще важно при выборе?
    Пожалуй, цена вопроса. Так, для разработки на PHP Вам достаточно (если я не ошибаюсь) любого бесплатного редактора (Eclipse, Aptana, Codelobster, ...) и бесплатного веб-сервера Apache. Что касается разработки под ASP.NET MVC (да и вообще на стеке технологий .NET), то тут у Вас есть 2 пути:
    1) использование free Express-версий продуктов (Visual Studio, MS SQL Server)
    2) соответственно, использование платных версий тех же продуктов.

    И еще пару моментов:
    1. Узнайте, состоит ли Ваш универ в альянсе Microsoft Academy Alliance (или как-то так). Мой универ состоял, и нам в Dreamspark были доступны все платные продукты за бесплатно - VS вплоть до Ultimate, MS SQL Server, все версии Windows и др. (естесственно, "в образовательных целях"). Если состоит, то узнайте у Ваших IT-преподователей, как получить доступ. Когда учился в универе, меня регистрирова препод, а потом на мой email пришло письмо на english, что-то вроде "ура, вы зарегистрированы, ваши данные для входа такие-то...".
    2. Если п.1 не сработал, то есть сайт - ИНТУИТ. Закончив там (вроде бы достаточно только 1 курса) курс от Microsoft, вы получаете ключ для регистрации на Dreamspark, в котором Вам открываются след.возможности:
    - Visual Studio all versions professional
    - MS SQL Server all versions
    - Windows + Windows Server
    И это, опять-таки, все бесплатно.

    По поводу Вашей темы диплома.
    Лично я немного не согласен с @SamDark в том плане, что "важна тема диплома, ее новизна и практическое значение". Новизна и практическое значение важны больше при разработке и защите различных диссертаций (докторских и какие там еще есть?), чем для диплома. Ваша идея, считаю, отличная, и неважно, что кто-то говорит, что "таких много". Да, много, но можно предложить свое решение задач, которое будет интереснее, красивее, удобнее, дешевле, проще, ... (нужное подчеркнуть). Если Вам эта тема интересна, и, что называется, тревожит душу, то беритесь за нее. Важна не идея, а ее реализация. К примеру: zappos.com - интернет-магазин обуви. Вроде бы чертова обувь... А если присмотреться, то их бизнес уникален (точнее, уникально предложенное ими решение проблемы - покупка обуви в интернете). Или basecamp от 37signals - вроде бы система управления проектами. А ведь Microsoft Project - тоже система управления проектами. Но на мой субъективный взгляд они и рядом не стоят. Разница в идее? Нет. Разница в реализации. А если получится действительно хороший продукт, то можно его превратить в SaaS и получать за это свои кровные.

    Надеюсь, я Вам немного помог в Вашем выборе.
    Ответ написан
  • Я не умею готовить репозиторий или он просто не очень?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Коллеги, добрый день!

    Почему никто не упомянул про паттерн UnitOfWork? Паттерн репозиторий становится очень удобным в использовании, если:
    1. это паттерн GenericRepository;
    2. при необходимости можно добавить конкретные репозитории (я их называю ConcreteRepository;
    3. ну и конечно же, если всем этим управляет UnitOfWork;


    При использовании такой связки у Вас:
    • если много сущностей и есть GenericRepository, то вам не нужно плодить репозиторий на каждую сущность - достаточно сделать так: var unit = UnitOfWork.Repository<UserLog>();
    • пункт выше автоматически решает проблему "как выбрать данные из 2-3-4-... таблиц" - с репозиториями вы работаете как с DbSet в EF (кстати, сам DbContext из EF, по сути, реализует паттерн UnitOfWork и GenericRepository);
    • автоматически решается вопрос расширения вашего репозитория методами на каждый чих (т.е. надо получить список логов для конкретного пользователя - добавляем новый метод GetLogsByUserId в репозиторий) - не нужно накручивать репозиторий новыми методами, достаточно сделать так: var unit = UnitOfWork.Repository<UserLog>().GetQuery(e => e.UserId == targetUserId) или var unit = UnitOfWork.Repository<UserLog>().AsQuaryableQuery(e => e.UserId == targetUserId) (методы GetQuery и AsQuaryableQuery - это методы у сущности UnitOfWork, которые возвращают IEnumerable или IQueryable соответственно);
    • если методы SaveChanges/Commit реализованы в UnitOfWork (и UnitOfWork управляет транзакциями БД), то у вас решается проблема консистентности данных - UnitOfWork либо подтверждает все изменения (Commit), либо откатывает в случае ошибок (Rollback);
    Или мне спецальный класс завести в которомом сразу будут все репозитории(как dbContext прям)?

    Правильно мыслите - этот специальный класс и есть UnitOfWork. Он "прям как dbContext", только таким образом вы абстрагируетесь от всяких EF, NHibernate и прочих ORM. В итоге вашей бизнес-логике по барабану, какую ORM вы используете.

    Если мне нужен в 1 контроллере/сервисе не 1 репозиторий? мне по 1 их подключать? может мне 15 надо.

    Достаточно подключить 1 UnitOfWork (и лучше это делать через внедрение зависимостей - DI - DependencyInjection с использованием IoC-контейнера, например, Autofac, Ninject, Unity. Autofac лично мне нравится больше хотя бы потому, что у него самая адекватная и понятная документация, чем у Ninject и уж тем более Unity [нет, это не тема для холивара "кто лучше: Autofac/Ninject/Unity/... - это всё выводы из моего личного опыта]).

    И главный вопрос. Нужно ли вообще применять этот паттерн если ты не используешь юнит тестирование, либо не используешь его для покрытия 100% всего кода а только отдельные хелперы? Ведь для перехода на другую бд достаточно будет сменить провайдер если используешь ef, и если вы используете орм врядли вы полностью от неё откажетесь. Зачем писать кучу кода "наперед" с принципом "а вот вдруг мы поменяем бд/ос", да это скорей всего уменьшит изменения кода по сравнению с полной переписыванием проекта. Но если ты уверен что ос и бд не поменяется?

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

    СУБД менять - это не такая распространенная практика, а вот от ORM (и от EF в частности) отказываться в пользу производительности - это реальный кейс с ростом нагрузки.

    Толстый Лорри - абсолютно с Вами согласен по этому поводу.

    Михаил очень в тему упомянул принцип единственной ответственности. 1 компонент - 1 ответственность. По себе заметил - если следовать хотя бы этому принципу, то уже автоматически система становится модульной. А раз есть модули, то можно снизить степень связанности компонентов между собой, используя абстракции (интерфейсы и абстрактные классы). А раз есть абстрагирование между компонентами, то юнит-тестирование будет только в радость. Причем компонентом может выступать как класс, так и целый проект. Например, в отдельный проект можно вынести какой-нибудь модуль системы, и затем этот проект можно подключить в другую систему при разработке. Таким образом повышается степень повторного использования кода (зачем 2 раза делать одно и то же?).

    Михаил еще также указал в комментарии, в каких случаях репозиторий можно не использовать. Добавлю: в не-enterprise-решениях. Например, вы делаете какой-нибудь простенький сайт для себя. Или для друга. Или просто для изучения новой технологии.
    Ответ написан
  • Переход. From ASP.NET To ASP.NET MVC?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!
    По собственному опыту могу сказать, что ASP.NET MVC показался мне более понятным, простым, ясным и прозрачным, чем "эти ужасные" (уж извините за субъективное мнение) ASP.NET WebForms. Начал свое знакомство с ASP.NET именно с WebForms, потом перешел на MVC - моему счастью не было предела.

    По Вашим "стадиям":
    1. Когда изучите ASP.NET MVC по книге "ASP.NET MVC x для профессионалов" (x - номер версии).
    2. Здесь все очень субъективно и зависит от самих проектов и их задач. Можно написать 15 проектов на MVC, но они все будут как один. А можно написать 2 проекта на MVC, но при этом они могут различаться настолько, что имея за плечами всего пару проектов, Вы уже будете знать наизусть весь MVC, C#, Entity Framework, JavaScript и паттерны проектирования в придачу.

    Можно, конечно, всю жизнь лепить проекты на WebForms, но я бы Вам настоятельно рекомендовал все новые проекты делать уже исключительно на MVC. Тем более что за неделю Вы сможете его спокойно изучить по книге (при условии полного рабочего дня).
    Ответ написан
  • Как зашифровать (обфускатор) код в c#?

    Valeriy1991
    @Valeriy1991
    Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
    Добрый день!

    Как вариант - написать свой обфускатор (на полном серьезе). Например, строки можно кодировать в Юникод (вида \u0024), добавлять рандомно кучу комментариев, точек с запятыми, переименовать все переменные в переменные с бредовыми названиями, используя Guid.NewGuid(). Например:
    было:
    private string _appName = "MyApp";
    стало:
    private string 2D63C163DBAF484E8B2286DCD3BE3FD4= "\u0023\u0054"; // как-то так

    Можно вдобавок удалить все #region'ы и #endregion'ы, сделать так, чтобы всё содержимое *.cs файлов было в 1 строку (только это не работает, если у Вас есть директивы препроцессора: #if, #endif и др. - эти директивы обязательно должны быть на новой строке), удалить все нормальные комментарии (которые оставляли разработчики), добавлять какой-нибудь ненужный код в виде циклов.

    Удачи!
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (6)