[Developer's community]

C# 4.0 Описание новых функций

 

25 January 2011
C# 4.0 Описание новых функций

C# представляет собой развивающийся язык. В этой статье рассматриваются новые функции, добавленные в C # 4.0 (а также короткое описание нововведений в предыдущих версиях), что в совокупности улучшает читаемость кода и предоставляет вам возможность использовать LINQ для запросов к динамическим источникам данных. Примеры, приведенные в этом обзоре показывают пути улучшения модели кодирования для чтения данных из различных источников, включая текстовые файлы, и каким образом объединять данные из COM-Interop источника для LINQ запросов к объектам.

C# 2.0
Generics/Обобщения – новая возможность языка, позволяющая создавать обобщенные алгоритмы, Итераторы (yield keyword) – механизм, упрощающий создание перечислителей (реализации интерфейса IEnumerable), Анонимные методы/anonymous methods (delegate keyword) – возможность инициализировать делегаты телами методов, Partial types (классы) – возможность разбивать код одного класса по нескольким файлам, упрощенный синтаксис инициализации делегатов.

C# 3.0
Ключевые слова select, from, where, позволяющие делать запросы из SQL, XML, коллекций и т. п. (запрос, интегрированный в язык, Language Integrated Query, или LINQ), Инициализация объекта вместе с его свойствами, лямбда-выражения ( lambda expressions (=>)), деревья выражений (лямбда-выражения могут представляться в виде структуры данных), безымянные типы (var-ы), методы-расширения — добавление метода в существующий класс с помощью ключевого слова this при первом параметре статической функции, автоматические свойства.

Важно! C# 3.0 совместим с C# 2.0 по генерируемому MSIL-коду, улучшения в языке — чисто синтаксические и реализуются на этапе компиляции.

Улучшения в C# 4.0
Microsoft разделила новые функции на следующие четыре категории:
•    Именованые и необязательные параметры
•    Динамическое связывание
•    Ковариантность и контрвариантность
•    Улучшенное взаимодействие с COM

Соглашения
Для рассмотрения примеров, будем считать, что опрелены следующие классы:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}
public class Customer : Person
{
    public int CustomerId { get; set; }
    public void Process() { ... }
}
public class SalesRep : Person
{
    public int SalesRepId { get; set; }
    public void SellStuff() { ... }
}
 

Именованые и необязательные параметры
Поддержка необязательных параметров позволяет передать методу значение по умолчанию, следовательно вы не должны указывать его при каждом вызове метода. Это очень удобно, когда у вас есть несколько перегруженных версий метода. "Древний" подход выглядел так:

public void Process( string data )
{
    Process( data, false );
}
public void Process( string data, bool ignoreWS )
{
    Process( data, ignoreWS, null );
}
public void Process( string data, bool ignoreWS, ArrayList moreData )
{
    //Наш код
}
Причиной перегрузки метода Process является намерение избежать необходимости постоянно включать "false, null" в третьем вызове метода. Теперь предположим, что в 99% случаев динамический массив 'moreData' не будет предоставляется - с этой т.з. выглядит "неправильным" передавать null так много раз:
Следующие 3 вызова эквивалентны

Process( "foo", false, null );
Process( "foo", false );
Process( "foo");

Новый подход выглядит так:

public void Process( string data, bool ignoreWS = false, ArrayList moreData = null )
{
    // Наш код
}

// Примечание: строковая переменная data должна передаваться всегда, т.е. у нее нет значения по умолчанию
Теперь у нас есть всего лишь один метод Process вместо трех, но те три способа вызова, которые мы рассматривали выше все еще работают (и эквивалентны между собой):

ArrayList myArrayList = new ArrayList();
Process( "foo" ); //Правильный вызов
Process( "foo", true ); //Правильный вызов
Process( "foo", false, myArrayList ); //Правильный вызов
Process( "foo", myArrayList );
// Неправильно! См. ниже описание именованых парамертов...

Именованые параметры
В предыдущем примере (выше) мы увидели, что следующий вызов неправилен:

Process( "foo", myArrayList );
Давайте разберемся: если булева переменная ignoreWS не обязательна (т.е. носит опциональный характер), почему мы не можем просто проигнорировать/опустить ее? Важными причинами могут являтся читабельность и сопровождаемость написанного кода, но, что еще более важно - при таком "подходе" невозможно узнать какой из параметров вы пытаетесь передать, т.е. если у вас к примеру два параметра одного и того же типа, то компилятор не может узнать какой из них вы имеете ввиду. Представьте себе метод с 10-ю необязательными параметрми и вы передаете ему только один ArrayList. Так как ArrayList наследуется от object, IList и IEnumerable, то становится невозможным определить, каким образом его использовать. Теперь думаю понятно в чем трудность. В свою очередь, "именованые параметры" предоставляют элегантное решение:
ArrayList myArrayList = new ArrayList();
Process( "foo", true ); // это правильный синтаксис, и moreData проигнорирован
Process( "foo", true, myArrayList ); //это также правильный синтаксис
Process( "foo", moreData: myArrayList); //это правильный синтаксис и ignoreWS проигнорирован
Process( "foo", moreData: myArrayList, ignoreWS: false ); //Правильно, но не приемлимо...
Имейте ввиду то, что если параметр имеет значение по умолчанию, его можно опустить. 

Динамическое связывание (Dynamic binding)

Пожалуй наибольшей инновацией в C# 4.0 является динамическое связывание (Dynamic binding). Реализация данной функции в C# была стимулирована примерами таких динамических языков как Python, Ruby, JavaScript и SmallTalk. Динамическое свзяывание "откладывает" связывание (процесс определения типов и членов) с этапа компиляции до времени выполнения. Хотя C# остается преимущественно статически типизированным языком - переменные типа "dynamic" определяются методом "позднего связывания". Ну ОК, давайте перейдем от слов к делу :) Уверен Вы имели дело с кодом, наподобие этого:

public object GetCustomer()
{
    Customer cust = new Customer();
    ...
    return cust;
}
...
Customer cust = GetCustomer() as Customer;
if( cust != null )
{
    cust.FirstName = "foo";
}

Примите во внимание, что метод GetCustomer возвращает object.

Материалы взяты с сайта www.codeproject.com

Оператор JOIN для чайников

 

21 January 2011
Данная статья будет полезна новичкам и поможет в освоении оператора JOIN и  в этом примере он б

Данная статья будет полезна новичкам и поможет в освоении оператора JOIN и  в этом примере он будет рассмотрен в контексте языка T-SQL. Для визуализации работы запросов были также использованы диаграммы Венна, которые, как я надеюсь помогут вникнуть в смысл JOIN-ов. Для начала работы над примерами - предположим, что у нас есть 2 таблицы ('Таблица_1' слева и 'Таблица_2' справа), давайте заполним их тестовыми данными:

 

Таблица_1 Таблица_2
id name id name
-- ---- -- ----
1 Машина 1 Паром
2 Грузовик 2 Машина
3 Самолет 3 Велосипед
4 Поезд 4 Самолет

 

Теперь, когда мы разобрались с условностями - можно переходить к рассмотрению примеров:

1. INNER JOIN выводит только те записи, которые совпадают в обеих таблицах

SELECT * FROM Table_1
INNER JOIN Table_2
ON Table_1.name = Table_2.name

Результат работы запроса:

 

id   name id name
--   ---- -- ----
1   Машина 2 Машина
3   Самолет 4 Самолет

 

 

 2. FULL OUTER JOIN выводит набор записей, которые совпадают в обеих таблицах (с двух сторон), там, где нет совпадения вставляется значение NULL (сравнение записей ведется с Таблицей_1, т.е. той, что с левой стороны).

SELECT * FROM Table_1
FULL OUTER JOIN Table_2
ON Table_1.name = Table_2.name

Результат работы запроса:

 

id   name id name
--   ---- -- ----
1   Машина 2 Машина
2   Грузовик NULL NULL
3   Самолет 4 Самолет
4   Поезд NULL NULL
NULL   NULL 1 Паром
NULL   NULL 3 Велосипед
 

 3. LEFT OUTER JOIN выводит полный набор записей из первой таблицы (в нашем случае Таблица_1), и совпадающие записи (где это возможно) со второй таблицы (Таблица_2). Если совпадений нет - в поле вставляется значение NULL.

SELECT * FROM Table_1
LEFT OUTER JOIN Table_2
ON Table_1.name = Table_2.name
id   name id name
--   ---- -- ----
1   Машина 2 Машина
2   Грузовик NULL NULL
3   Самолет 4 Самолет
4   Поезд NULL NULL
 

 4. RIGHT OUTER JOIN выводит полный набор записей из второй таблицы (в нашем случае Таблица_1), и совпадающие записи (где это возможно) из первой таблицы (Таблица_1). Если совпадений нет - в поле вставляется значение NULL. Как мы видим этот оператор похож на предыдущий, только в данном случае "ведущей" будет вторая таблица (с правой стороны).

SELECT * FROM Table_1
RIGHT OUTER JOIN Table_2
ON Table_1.name = Table_2.name
id   name id name
--   ---- -- ----
NULL   NULL 1 Паром
1   Машина 2 Машина
NULL   NULL 3 Велосипед
3   Самолет 4 Самолет
 

 5. Извлечение уникальных записей из таблицы посредством оператора WHERE. В данном примере мы выведем только те записи из Таблицы_1, которых нет в Таблице_2.

SELECT * FROM Table_1
LEFT OUTER JOIN Table_2
ON Table_1.name = Table_2.name
WHERE Table_2.id IS null
id   name id name
--   ---- -- ----
2   Грузовик NULL NULL
4   Поезд NULL NULL
 

 6. Извлечение уникальных записей из обеих таблиц посредством оператора WHERE. В данном примере мы выведем уникальные записи из Таблицы_1 и Таблицы_2.

SELECT * FROM Table_1
FULL OUTER JOIN Table_2
ON Table_1.name = Table_2.name
WHERE Table_1.id IS null 
OR Table_2.id IS null
id   name id name
--   ---- -- ----
2   Грузовик NULL NULL
4   Поезд NULL NULL
NULL   NULL 1 Паром
NULL   NULL 3 Велосипед
 

 7. CROSS JOIN. Для полноты изложения материала следует упомянуть еще об одном операторе - CROSS JOIN. Этот оператор используется довольно редко и для визуального представления нет подходящей диаграммы Венна. С помощью CROSS JOIN-а мы можем сделать перекрестную выборку всех записей из обеих таблиц (Таблицы_1 и Таблицы_2) и в нашем случае мы получим 4х4=16 строк данных. Возьмите на заметку, что лучше не применять этот опреатор для больших таблиц, т.к. это может серьезно повлиять на производительность СУБД.

SELECT * FROM Table_1
CROSS JOIN Table_2
   

Полезные скрипты (T-SQL), полное удаление данных из таблиц БД

 

20 January 2011

Иногда, во время тестирования, бывает нужно удалить все данные из какой-нибудь конкретной БД (сценариев использования на самом деле больше). Вручную это делать неинтересно и временами нереально (при больших объемах данных), к тому-же,  было-бы неплохо обнулить нумерацию в таблицах. Для это вводим следующий скрипт:

 

EXEC sp_MSForEachTable 'ALTER TABLE ? NOCHECK CONSTRAINT ALL'  
GO  

EXEC sp_MSForEachTable '  
  IF OBJECTPROPERTY(object_id(''?''), ''TableHasForeignRef'') = 1  
  DELETE FROM ?  
  else   
  TRUNCATE TABLE ?  
'  
GO  
  
EXEC sp_MSForEachTable 'ALTER TABLE ? CHECK CONSTRAINT ALL'  
GO  

EXEC sp_MSForEachTable '   
IF OBJECTPROPERTY(object_id(''?''), ''TableHasIdentity'') = 1   
DBCC CHECKIDENT (''?'', RESEED, 0)   
'   
GO

 

Первая часть скрипта отключает контроль ссылочной целостности, затем удаляет все данные из всех таблиц (строки 1-10). Вторая чать скрипта включает контроль ссылочной целостности (строки 11-12). И последний кусок кода кстанавливает начальные значения счетчиков в 0 (оператор RESEED).

Управление хаосом

 

17 January 2011
Возвращение к началу называю покоем,
Покой называю возвращением к сути,
Возвращение к сути есть постоянство,
Постоянство есть возвращение к ясности,
Избегаешь постоянства — следуешь хаосу,
Хаос приводит к злу,
Познал постоянство — стал совершенным.
Совершенный неизменно справедлив...

                                                            (Лао Цзы)

Построение на новых началах.

 

Вас захватил стремительный круговорот событий, и вы не можете разобраться, где верх, а где низ, что происходит и что делать со всем этим? Нет, сейчас мы не будем заниматься анализом психологических проблем. Цель этой статьи – понять, как современный бизнес может приспособиться к быстро изменяющейся окружающей среде. Речь пойдёт о популярной сегодня теории competingontheedge («конкурирование на острие»). Она пытается дать ответ на вопрос:можно ли управлять хаосом и как это делать?

Теория competingontheedge появилась благодаря книге Шоны Браун и Катлин Айзенхардт «Конкурирование на острие: стратегия структурированного хаоса» (ShonaBrownandKathleenEisenhardt, CompetingontheEdge: StrategyasStructuredChaos). Этот подход относится к иррациональным школам стратегического управления и в своей философской части базируется на физической теории хаоса. КНО – не столько инструментальная, сколько мировоззренческая теория.

AtlantaBraves, Microsoft, 3M, Nike и Intel -- что общего между этими организациями? Шона Браун и Катлин Айзенхардт считают, что они предсказуемо непредсказуемы. Они являются лидерами не потому, что умеют прогнозировать, а потому, что умеют балансировать на грани хаоса и порядка. Именно пребывание на этой грани позволяет им быть инновационными, креативными и одновременно поддерживать уровень дисциплины, достаточный для того, чтобы не выбиваться из намеченного плана. Данная теория не призвана помочь вам наиболее оптимально или предсказуемо построить бизнес, зато её применение позволит вашей компании выжить и адаптироваться к быстроменяющейся среде.

 

Чтобы достичь такого состояния, необходимо придерживаться трёх правил:

1.      Быть на рубеже хаоса;

2.      Балансировать на острие времени;

3.      Следовать темпу времени.

 

 

      Такой вариант символа хаоса был придуман американским писателем-фантастом Майклом Муркоком (Michael John Moorcock).

 

 

Рубеж хаоса – это естественное состояние между порядком и хаосом, золотая середина между заструктурированностью и беспозвоночностью. Быть на рубеже хаоса значит быть частично структурированным, т.е. найти оптимальное количество связей, планов и правил. В отличие от рациональных стратегий, теория конкурирования на острие рассматривает не форму, а оптимальное количество стратегии. Находясь в точке оптимума, организационные системы остаются наиболее гибкими и способными к самоорганизации.

Балансирование на острие времени подразумевает то, что нужно жить сегодняшним днём, никогда не упуская из вида прошлое и будущее. Если  исходить лишь из прошлого опыта, то мы рискуем постоянно воспроизводить уже устаревшие конкурентные стратегии. А думая исключительно о перипетиях завтрашнего дня, легко можно увлечься планированием.

Следование темпу времени – самый необычный и парадоксальный принцип. Он означает, что темп изменений задаётся намеренно. Например, устанавливается правило, по которому предприятие выходит на рынок с новым продуктом или услугой через каждые шесть месяцев, а не тогда, когда необходим ответный конкурентный шаг. Так действует компания 3M: 30% их текущего выпуска должны приходиться на продукцию, разработанную в последние 4 года. Это правило не обусловлено каким-либо глубоким и скрупулёзным анализом, ибо среда меняется настолько быстро, что проводить такой анализ просто бесполезно. Таким образом, вы сами создаёте темп, который дисциплинирует вашу организацию, позволяет постоянно обновляться, а также заставляет ваших конкурентов подстраиваться под этот темп.

 

Опасности на пути к лучшему

 

Каковы же принципы деятельности организации, конкурирующей на острие? Её корпоративная культура признаёт, что изменения – это норма, а не исключение. Идеалом степени структурированности являются полуструктуры. Это значит, что менеджеры отслеживают не всю деятельность персонала, а лишь исполнение основных заданий, оставляя  свободу действий и инициатив до той поры, пока они не противоречат стратегии. За счёт этого-то и появляется гибкость и адаптивность организации. Согласованность общего направления действий поддерживается благодаря высокоинтенсивным коммуникациям в режиме реального времени.

Чтобы быть более конкретными, приведём в пример две крайности, в которые очень легко скатиться. Это ловушки под названием структура и сюрприз. Если вы вдруг обнаружите похожие черты, то задумайтесь: возможно, пора пересмотреть степень структурированности в вашей организации?

Итак, первая ловушка – ловушка хаоса, или «сюрприз».

В таких компаниях царит творческая атмосфера, но они не в состоянии реализовать свои идеи, довести начатое до конца. Их корпоративная культура призывает низвергать правила. Это не только приемлемо, но и приветствуется. В таких организациях сотрудник либо теряется, либо выступает с креативной инициативой, не вписывающейся в общее направление движения. Если вам вспомнилась басня про лебедя, рака и щуку, то это как раз та самая ситуация. Отсутствие чётко установленных сроков позволяет избегать контроля до той поры, пока организация ещё каким-то чудом выживает. Свой вклад в общую какофонию вносит также и размытая ответственность. Зачем отвечать за что-то самому, когда можно свалить всё на обстоятельства, либо перевести стрелки на коллегу? Выполнение обязанностей замещает бурная деятельность, а также случайные и высокоинтенсивные коммуникации.

Но не будем винить данные организации в сложившейся ситуации. Просто если вы заметили подобные тенденции в своём бизнесе, пора наклонить балансир в противоположную сторону – от анархии к порядку.

Вторая ловушка – бюрократическая. Корпоративная культура бюрократизированной организации, напротив, поощряет неотступное следование правилам, порой даже вопреки изменениям в окружающей среде. Ценится предсказуемость и контроль, а любое изменение вызывает отторжение. Все организационные процессы чётко определены, коммуникации протекают исключительно по формальным каналам и только в прописанных заранее случаях. Инициатива не приветствуется.

Излишняя структурированность грозит хрупкостью системы: при любом изменении внешней среды жёсткую иерархическую систему придётся перестраивать «сверху», что займёт много времени. Сама же она адаптироваться не сможет, т.к. на всех уровнях, кроме самого верхнего, не будет ни полномочий, ни инициативы, ни навыков адаптации.

 

Держаться золотой середины.

 

Пребывание на рубеже хаоса налагает определённые требования и на поведенческие навыки сотрудников. В основе их поведения должны лежать импровизация и коадаптация. Последняя подразумевает такой тип сотрудничества нескольких бизнес-систем, при котором все участники получают взаимные преимущества, позволяющие им не только более эффективно функционировать, но и быть более адаптивными к конкретной ситуации. Подразумевается, что все бизнес-единицы должны работать на победу одного лидера, находящегося среди них. Импровизации лучше всего поучиться у джаз-бэнда. Вам приходилось удивляться, как музыкантам удаётся воспроизводить узнаваемую мелодию неповторимым образом, не репетируя заранее, а в режиме реального времени взаимодействуя друг с другом, фантазируя и всё же не сбиваясь с пути? Всё это происходит благодаря правилам, которым вы можете научить своих сотрудников:

1.      в любой момент исполнения мелодии знай, кто солист;

2.      пробуй новые подходы и стили на знакомых отрезках;

3.      солист должен слушать всех и выстраивать мелодию из работы других членов группы;

4.      будь готов к внезапному «крушению поезда». Восстанавливайся и продолжай играть.