ВоITи и выITи

At any place I work there are was a moment with discussion about using of break. continue and goto operators. I read a lot about goto in books and even McConnel "Solid code" wrote about how it is bad. And in all these places, in code styles, style guides and books, there are only one point: missing the main line of code or loosing the control. But I belive that with correct splitting of the program to smaller parts (methods, functions, classes) and with solid architecture there are no such a big deal about loosing control by using just break or continue. Sometimes it makes code shorter and easier. Recently I read very good article (or is this a book?)  What every programmer should know about memory  I found good example of why we should not use operators which lead to assembly JUMP from the real performance point of view: ( here is ) and it is called Prefetching. "Code has the advantage that it is linear between jumps. In these periods the processor can prefetch

Где бы мне ни приходилось работать, везде в какой-то момент возникает дискуссия на тему использования или неиспользования операторов break, continue и, конечно же, goto. О goto я читал в книгах, по-моему даже МакКоннел "Совершенный код", или что-то вроде. В руководствах по кодированию (code style, code guide) и в книгах довод один: запутанность кода. Однако при правильном разбиении кода на методы и нормальной архитектуре, по-моему, break и continue приводит только к большей понятности кода. И вот, читая интереснейший цикл статей "Что каждый программист должен знать о памяти" я нарвался на доступное объяснение чем плох любой переход (JUMP) с точки зрения производительности (ссыль http://rus-linux.net/lib.php?name=/MyLDP/hard/memory/memory-6-3.html ): "Код имеет то преимущество, что между переходами он линеен. В такие периоды процессор может эффективно делать предварительную загрузку памяти. Переходы нарушают эту идеальную картину из-за того

Недавно я перевёл свой проект с рельс ASP.NET MVC 3 на рельсы распоследней ASP.NET MVC 5. В статье я подробно описал как при этом использовать свои собственные таблицы БД и классы моделей, но остаться в рамках реализации стандартного механизма ASP.NET Identity. Одним из плюсов свежей версии я назвал поддержку OAuth 2.0 "из коробки". Однако, когда я дошёл до необходимости связывания MVC проекта с WebAPI встал вопрос о реализации аутентификации и авторизации пользователей. И здесь начались слёзы... Я очень советую всем посмотреть недавно вышедший курс по безопасности в Web API 2.0: WebAPI 2.0 Security Ссылку на скачивание с rutracker найдёте сами =). Это экспресс-курс, в котором описывается базовая настройка SSL, введение в основные виды аутентификации в ASP.NET, безопасность JavaScript клиентов, а также Token Based Authentication. Ну и конечно же описание проблем WebAPI 1.0 и решений этих проблем в WebAPI 2.0. Однако, по ходу курса непременно затрагивается вопрос работы O

Not so far I moved my ASP.NET MVC 3 project to latest&greatest ASP.NET MVC 5. In my previous article I was writing about this process and how to use own datatables for ASP.NET Identity 2.0 model. One of the points for latest version was OAuth 2.0 "out of the box". But now I have to implement authentication in my Web API project part and read a lot about it...and here is tears... I recommend to see one of the latest courses about Security in Web API 2.0:  WebAPI 2.0 Security You may see this course available on  rutracker  =). This is express-course but it is very usefull and telling about SSL settings in your web server, main authentication mecanisms and capabilities in ASP.NET, client-side security in JavaScript, and also Token Based Authentication. Also there are good describing of problems in WebAPI 1.0 and how it was solved in WebAPI 2.0. During this course there are touched OAuth 2.0 a lot and there are gived link to another useful course  Introduction to OAuth2,

Recently I found a nice explanation of latest  Securing (ASP.NET) web API-based architectures  from DevWeek about the totally new ASP.NET Identity 2.0  in  MVC 5.1  and  Web API 2.0  and I decided to rework my current project to use it because 1. New system built on open standard  OWIN , which allows to take a look 'What's inside?' and gives some flexibility in choosing web-server and OS. 2. Owin-based authentication natively supports security for Web API 2.0. 3. Latest projects contains OAuth 2.0 authentication out of the box. I think many of ASP.NET MVC 1 - 4 web-developers rework standard Forms authentication provided by Microsoft. I did this too. I had overrided Membership Provider, Roles Provider and Identity, and you may find a lot of  examples . But there are no so much information about  ASP.NET Identity 2.0 , so I think my post will cover it nicely. As you know, when you create a new project from ASP.NET MVC template, it create default database for you which

Посмотрев видео Securing (ASP.NET) web API-based architectures с DevWeek о новой системе безопасности и аутентификации ASP.NET Identity 2.0 в последней версии MVC 5.1 и Web API 2.0 я решил, что надо бы свой проект перенести на новые рельсы, потому что 1. Новая система безопасности создана по открытой спецификации OWIN , что позволяет немного глубже заглянуть «под капот», да и в будущем может дать большую гибкость в выборе ОС и сервера. 2. В новой системе безопасности нативно поддерживается безопасность Web API 2.0, что мне как раз и нужно. 3. В новых проектах из коробки поддерживаются OAuth 2.0 аутентификация. Полагаю, что при разработке на ASP.NET MVC 1 - 4, многие избавляются от стандартной системы Forms аутентификации от Microsoft. Я это делал переопределением Membership Provider, Roles Provider и Identity, в общем, примеров в сети достаточно . Однако, по новой системе ASP.NET Identity 2.0 информации пока не так уж и много, поэтому мой пост должен быть полезен. Как извес

Между парадигмами разработки с Entity Framework (Code First, Model First, Database First) я выбрал промежуточную, потому что ни одна меня не устраивала полностью. В Code First меня радуют чистые POCO классы, но не устраивает невозможность моделирования базы. В Database First и Model First мне не нравится генерация EDMX и другого всего лишнего. Таким образом, я нашел для себя такое решение: 1. Я моделирую схему в любой удобной программе (тут любая внешняя программа моделирования, генерирующая SQL Server-совместимые скрипты генерации базы) Рис. Смоделированная схема БД. 2. Создаю базу в SQL Management Studio 3. Делаю Reverse Engineering базы в POCO классы (как в Code First) с помощью плагина Entity Framework Power Tools Рис. Установленный плагин для Reverse Engineer. Рис. Вот так делается Reverse Engineer базы данных в POCO классы. Рис. Результат генерации POCO классов на основе базы данных: папочка Models с готовым контекстом, классами объектов и маппинг-классами.

Between 3 most known practices of Entity Framework (Code First, Model First, Database First) I selected one happy medium, because no one is perfect by itself. I like clean POCO classes of Code First, but it is not so easy to handle a good scheme/structure of database without modelling. In Database First and Model First I don't like EDMX files and a lot of redundancy. So I found a perfect solution for me: 1. I do modelling in any Modelling tool which supports generating SQL scripts for SQL Server. Picture. Part of ready scheme. 2. Create database and execute script in SQL Management Studio 3. And... here is... make a Reverse Engineering of database into model POCO classes (just like Code First) with Visual Studio plug-in: Entity Framework Power Tools Picture. Plugin for Reverse Engineering installed. Picture. Here command to select for Reverse Engineering. Picture. Result is POCO classes in the Models folder of my Model project. It includes database context, classes and mapping-clas