29.4.Класс стек на основе связного списка
|
29.5.Чтение текстового файла
В данной программе иллюстрируется чтение данных разных типов из текстового файла. Содержимое файла может быть таким:
Прогульщиков 12,5 1992
Ленивый 23,5 1993
Красивая 9060,90 1994
Разделителем полей записи выбран пробел, но пробел в конце записи файла не допускается. Текстовый файл с символами кириллицы надо сохранить в колировке Unicode:
File->Advanced Save Options->Encoding->Unicode (UTF-8 ...) - CodePage 65001
Файл проще всего разместить в каталоге debug проекта или использовать стандартный диалог по получению имени файла.
|
|
|
|
Стандартный диалог по выбору имени файла можно организовать так:
using System;
using System.IO; // необходимо для использования Directory.GetCurrentDirectory()
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.ComponentModel;
//using System.Data;
//using System.Drawing;
using System.Windows.Forms; /* необходимо для использования OpenFileDialog */
class Program
{
[STAThreadAttribute]// необходимо для использования OpenFileDialog
static void Main(string[] args)
{
OpenFileDialog openFileDialog1 = new OpenFileDialog();
openFileDialog1.DefaultExt = "txt";
openFileDialog1.Filter = "Text files (*.txt)|*.txt";
openFileDialog1.InitialDirectory =
Directory.GetCurrentDirectory();
if (openFileDialog1.ShowDialog() == DialogResult.OK)
{
/* читаем весь файл и выводим его содержимое в окно*
StreamReader sr = new
StreamReader(openFileDialog1.FileName);
MessageBox.Show(sr.ReadToEnd());
sr.Close();
}
}
}
30.Предпосылки возникновения com
Технология СОМ является одной из базовых технологий Windows и для того, чтобы понять ее назначение, необходимо рассмотреть основные предпосылки ее возникновения. Если попытаться кратко сформулировать ее цель – то это стандартизованный способ взаимодействия клиентских приложений и серверов или, как говорят, предоставление сервисов одним приложением другому. Таким образом, одной из главных предпосылок возникновения СОМ является именно проблема организации взаимодействия приложений.
Проблема взаимодействия приложений Windows имеет две стороны: взаимодействие на одном компьютере и в сети Intranet или Internet. Взаимодействие приложений, размещенных на удаленных компьютерах, обеспечивается технологией DCOM (Distributed COM – распределенная модель компонентных объектов), а также и технологией COM+. COM+ является следующим эволюционным шагом в развитии технологии СОМ. Технология COM+ не только включает в себя технологии COM и DCOM, но и имеет свои специфические особенности, облегчающие программирование взаимодействующих приложений Windows в рамках одного компьютера или в сети.
Чтобы яснее представить себе проблему взаимодействия приложений Windows, надо вспомнить следующее. Каждый процесс в 32-разрядной Windows имеет свое адресное пространство размером в 4Гб и, по этой причине, один процесс не имеет никакой возможности (и хорошо!) получить доступ к данным или функциям другого процесса, так как любой теоретически возможный адрес в процессе ссылается на свое адресное пространство.
В логической и хронологической последовательности взаимодействие приложений Windows реализовалось с использованием следующих основных технологий:
Dynamic Link Libraries (DLL) – динамически подключаемые библиотеки.
Open DataBase Connectivity (ODBC) – открытый интерфейс доступа к базам данных, встроенный в Windows.
Dynamic Data Exchange (DDE) – динамический обмен данными.
Object Linking and Embedding (OLE1.0) – внедрение и связывание объектов, основанное на механизме DDE.
OLE2.0 – OLE на базе COM.
Distributed COM (DCOM) – распределенная модель компонентных объектов.
COM+ – усовершенствованная технология COM.
Ну хорошо, скажете Вы, а зачем вообще приложениям необходимо взаимодействовать друг с другом? Если некоторому приложению необходимо, допустим, использовать электронные таблицы Excel, то почему бы ему не подключить соответствующую библиотеку DLL? Естественно, можно, и это уже было первым подходом к решению обсуждаемой проблемы. Однако такой подход имеет свои недостатки, главным из которых является проблема сопровождения и модификации ПП. Если разрабатывается новая версия какой-либо функции DLL, то перестают работать приложения, которые используют старую версию функции. Если новую версию функции снабдить новым именем, то необходимо разрабатывать новую документацию и включать в библиотеку обе версии функции. Несложно себе представить, в какой конгломерат превратится библиотека в течение весьма небольшого промежутка времени и насколько сложно будет ориентироваться в многочисленных версиях функций!
Главную идею технологии ODBC можно проиллюстрировать все на том же Excel. Так как это приложение должно быть способно считывать данные из БД различных форматов, необходимо или разрабатывать различные версии Excel для каждой из БД (Excel для Access, Excel для Oracle и т.д.) или заблаговременно подключать все необходимые библиотеки к Excel. Microsoft выбрала другой путь, создав промежуточный программный слой, который определяет стандартный интерфейс для приложений. На уровне вызовов этот интерфейс использует язык SQL, а реализация взаимодействия с БД обеспечивается драйверами, поставляемыми в форме DLL. Таким образом, ODBC располагается между приложением и источниками данных различных форматов (рис. 41.1).
|
Рис. 2. Архитектура ODBC
Технологию динамического обмена данными DDE можно рассматривать как попытку стандартизации обмена данными между приложениями. Вся идеология Windows основана на обработке сообщений (messages) и любые приложения могут обмениваться друг с другом сообщениями, используя общую очередь сообщений. Проблема, однако, состоит в том, что каждое из приложений должно знать протокол обмена данными, т.е. формат сообщений, и собственно сообщения Windows не позволяют передавать сравнительно большие объемы данных. Технология DDE как раз и предложила такой стандартный протокол, реализованный во многих приложениях. Главными недостатками DDE является сложность программирования, ненадежность и то обстоятельство, что приложения должны знать формат передаваемых данных.
Кроме DDE в Windows предлагаются и используются и другие способы взаимодействия приложений (см. подраздел «Межпроцессное взаимодействие»).
Технологию внедрения и связывания объектов OLE1.0 фирма Microsoft представила в 1991г. как попытку реализации объектно-ориентированного механизма взаимодействия приложений. Главной идеей OLE является концепция составного документа, который может содержать объекты других приложений. До OLE приложения могли обмениваться статическими снимками данных через буфер обмена Windows. Однако редактирование таких данных должно выполняться тем приложением, которое их породило, а после редактирования они вновь должны быть вставлены в документ. Если изменяются исходные данные, то, очевидно, должны изменяться данные и в составном документе. Однако, системный буфер обмена не имеет никаких средств поддержания таких связей. Более того, проблемы возникают и при перемещении исходных данных в новое место.
Внедренный с помощью OLE1.0 объект содержит статические данные (рисунок) и данные, необходимые для его редактирования. Для редактирования объекта пользователю приложения-контейнера необходимо щелкнуть по объекту, вследствие чего в отдельном окне запускается исходное приложение, породившее эти данные. По окончании редактирования пользователь может сохранить данные и эти данные будут обновлены и в приложении-контейнере.
Недостатками технологии OLE1.0 являются:
В силу того, что базовым механизмом OLE1.0 является DDE, который по своей природе асинхронен, то после вызова любой функции возврат управления происходит немедленно и требуется ожидать, в цикле, завершения требуемой операции.
Вследствие того, что для передачи данных между приложениями используется разделяемая глобальная память, то данные сначала копируются в нее, откуда они тут же могут быть вытолкнуты Windows в файл подкачки, вследствие чего замедляется работа приложения.
Связи OLE1.0 легко разрываются при перемещении файлов.
Пользователю часто бывает неудобно редактировать данные в отдельном окне.
Технология СОМ, как очередная важная ступень в ряду подобных ей концепций разработки взаимодействующих приложений, предоставляет объектно-ориентированный протокол связи между приложениями, открывающий следующие возможности:
инвариантный по отношению к языку программирования способ вызова, выполнения и управления объектами, размещенными в DLL или приложениях, из приложений Win32;
новый мощный стандартизованный способ получения прикладными программами сервисов, предоставляемых операционной системой, заменяющий устаревшие и неэффективные механизмы, основанные на DDE и OLE 1.0;
расширения для поддержки новых протоколов взаимодействия приложений, таких как интерфейсы баз данных или доступ к функциям DirectX;
взаимодействие распределенных приложений, выполняемых на компьютерах с различными аппаратными и программными платформами (СОМ и Corba ).