ВоITи и выITи

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