Лекции / РАЗРАБОТКА ПРИЛОЖЕНИЯ С КЛИЕНТ-СЕРВЕРНОЙ АРХИТЕКТУРОЙ
.pdfРАЗРАБОТКА ПРИЛОЖЕНИЯ С КЛИЕНТ-СЕРВЕРНОЙ
АРХИТЕКТУРОЙ.
1. Архитектура «Клиент-сервер»
«Клиент — сервер» — вычислительная или сетевая архитектура, в
которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми
клиентами.
Фактически клиент и сервер — это программное обеспечение. Обычно эти программы расположены на разных вычислительных машинах и взаимодействуют между собой через вычислительную сеть посредством сетевых протоколов, но они могут быть расположены также и на одной машине.
Программы-серверы ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файлов посредством HTTP, FTP, потоковое мультимедиа или работа с базами данных)
или в виде сервисных функций (например, работа с электронной почтой,
общение посредством систем мгновенного обмена сообщениями или просмотр web-страниц во всемирной паутине).
Поскольку одна программа-сервер может выполнять запросы от множества программ-клиентов, её размещают на специально выделенной вычислительной машине, настроенной особым образом, как правило,
совместно с другими программами-серверами, поэтому производительность этой машины должна быть высокой. Из-за особой роли такой машины в сети,
специфики её оборудования и программного обеспечения, её также называют сервером, а машины, выполняющие клиентские программы, соответственно,
клиентами.
Архитектура клиент-сервер определяет лишь общие принципы взаимодействия между компьютерами, детали взаимодействия определяют различные протоколы. Данная концепция нам говорит, что нужно разделять машины в сети на клиентские, которым всегда что-то надо и на серверные,
которые дают то, что надо. При этом взаимодействие всегда начинает клиент,
а правила, по которым происходит взаимодействие, описывает протокол.
Существует два вида архитектуры взаимодействия клиент-сервер:
первый получил название двухзвенная архитектура клиент-серверного взаимодействия, второй – многоуровневая архитектура клиент-сервер
(иногда его называют трехуровневая архитектура или трехзвенная архитектура, но это частный случай).
Принцип работы двухуровневой архитектуры взаимодействия клиент-
сервер заключается в том, что обработка запроса происходит на одной машине без использования сторонних ресурсов. Двухзвенная архитектура предъявляет жесткие требования к производительности сервера, но в тоже время является очень надежной.
На рисунке 24.1 представлена модель двухзвенной архитектуры клиент-
серверного взаимодействия.
Рисунок 24.1 – Двухзвенная архитектура клиент-серверного взаимодействия
Здесь четко видно, что есть клиент (1-е звено), который позволяет человеку сделать запрос, и есть сервер (2-е звено), который обрабатывает запрос клиента.
Если говорить про многоуровневую архитектуру взаимодействия клиент-сервер, то в качестве примера можно привести любую современную СУБД. Суть многоуровневой архитектуры заключается в том, что запрос клиента обрабатывается сразу несколькими серверами. Такой подход позволяет значительно снизить нагрузку на сервер из-за того, что происходит
распределение операций, но в то же самое время данный подход не такой
2
надежный, как двухзвенная архитектура. На рисунке 24.2 представлен пример многоуровневой архитектуры клиент-сервер.
Рисунок 24.2 – Трехзвенная архитектура клиент-серверного приложения
Если говорить в контексте систем управления базами данных, то первое звено – это клиент, который позволяет нам писать различные SQL запросы к базе данных. Второе звено – это сервер приложения, являющийся промежуточным звеном между клиентом и хранилищем данных, а третье звено – это движок СУБД, который интерпретирует запросы и реализует взаимодействие между клиентом и файловой системой.
2. Создание библиотеки классов
Библиотека классов определяет типы и методы, которые могут быть вызваны из любого приложения.
Нередко различные классы и структуры оформляются в виде отдельных библиотек, которые компилируются в файлы dll и затем могут подключать в другие проекты. Благодаря этому мы можем определить один и тот же функционал в виде библиотеки классов и подключать в различные проекты или передавать на использование другим разработчикам.
Создадим и подключим библиотеку классов для функционирования классов, которые будут присутствовать и в клиентской, и в серверной части приложения.
Возьмем имеющийся проект, созданный на предыдущей лабораторной работе. В структуре проекта нажмем правой кнопкой на название решения и
3
далее в появившемся контекстном меню выберем Добавить → Создать проект:
Далее в списке шаблонов проекта найдем пункт Библиотека классов
(.NET Framework):
Рисунок 18.3 – Создание библиотеки классов
Затем дадим новому проекту какое-нибудь название, например, MyLib.
После этого в решение будет добавлен новый проект, в нашем случае с названием MyLib:
Рисунок 18.4
По умолчанию новый проект имеет один пустой класс Class1 в файле
Class1.cs. Мы можем этот файл удалить или переименовать, как нам больше
нравится.
4
Например, переименуем файл Class1.cs в User.cs, а класс Class1 в
User. |
Определим в классе User простейший код для сущности |
||
«Пользователь»: |
|||
|
|
Листинг 24.1 – Класс «Пользователь» |
|
|
|
|
|
|
1 |
namespace MyLib |
|
|
2 |
{ |
|
|
3 |
[Serializable] |
|
|
4 |
public partial class User |
|
|
5 |
{ |
|
|
6 |
public int Id { get; set; } |
|
|
7 |
public string Login { get; set; } |
|
|
8 |
public string Password { get; set; } |
|
|
9 |
public string Role { get; set; } |
|
|
10 |
public virtual Professor Professor { get; set; } |
|
|
11 |
public virtual Student Student { get; set; } |
|
|
12 |
} |
|
|
13 |
} |
|
Теперь скомпилируем библиотеку классов. Для этого нажмем правой кнопкой на проект библиотеки классов и в контекстном меню выберем пункт
Перестроить.
После компиляции библиотеки классов в папке проекта в каталоге bin/Debug/ мы сможем найти скомпилированный файл dll (MyLib.dll).
Подключим его в основной проект. Для этого в основном проекте нажмем правой кнопкой на узел Ссылки и в контекстном меню выберем пункт
Добавить ссылку…:
5
Рисунок 24.5 – Добавление ссылки на библиотеку в основной проект
Далее нам откроется окно для добавления библиотек. В этом окне выберем пункт Проекты, который позволяет увидеть все библиотеки классов из проектов текущего решения, поставим отметку рядом с нашей библиотекой и нажмем на кнопку OK:
Рисунок 24.6
Если наша библиотека вдруг представляет файл dll, который не связан ни с каким проектом в нашем решении, то с помощью кнопки Обзор мы можем найти местоположение файла dll и также его подключить.
6
После успешного подключения библиотеки в главном проекте изменим
класс формы регистрации FormReg, чтобы он использовал класс User из библиотеки классов:
Листинг 24.2
1 |
using MyLib; |
2 |
using System; |
3 |
using System.IO; |
4 |
using System.Net.Sockets; |
5 |
using System.Windows.Forms; |
6 |
namespace LAB_5_OAIP |
7 |
{ |
8 |
public partial class FormReg : Form |
9 |
{ |
10 |
… |
11 |
} |
12 |
} |
В строке 1 происходит подключение пространства имен MyLib из библиотеки классов.
Для дальнейшей работы информационной системы с клиент-серверной архитектурой требуется в библиотеку классов приложения MyLib добавить следующие классы:
1. Класс Thesis, описывающий сущность «Дипломный проект» со свойствами:
«Тема дипломного проекта» (Name);
«Аннотация к дипломному проекту» (Annotation);
«Преподаватель, добавивший тему дипломного проекта»
(Professor).
Листинг 24.3 – Класс «Дипломный проект»
1namespace MyLib
2{
3[Serializable]
4public partial class Thesis
5{
6public int Id { get; set; }
7public string Name { get; set; }
7
8 |
public string Annotation |
{ get; set; } |
9 |
public virtual Professor |
Professor { get; set; } |
10 |
} |
|
11 |
} |
|
2. Класс Student, описывающий сущность «Студент» со свойствами:
«ФИО студента» (Name);
«Номер группа» (NumberGroup);
«Дополнительная информация о студенте» (PersonalData);
«Фотография студента» (Photo);
«Специальность» (Specialty);
«Учетная запись студента» (User);
«Преподаватель, являющийся руководителем дипломного проекта студента» (Professor).
Листинг 24.4 – Класс «Студент»
1 |
namespace MyLib |
2 |
{ |
3 |
[Serializable] |
4 |
public partial class Student |
5 |
{ |
6 |
public int Id { get; set; } |
7 |
public string Name { get; set; } |
8 |
public long NumberGroup { get; set; } |
9 |
public string PersonalData { get; set; } |
10 |
public byte[] Photo { get; set; } |
11 |
public string Specialty { get; set; } |
12 |
public virtual User User { get; set; } |
13 |
public virtual Professor Professor { get; set; } |
14 |
} |
15 |
} |
8
3. Класс Professor, описывающий сущность «Преподаватель» со
свойствами:
«ФИО преподавателя» (Name);
«Должность» (Position);
«Дополнительная информация о преподавателе»
(PersonalData);
«Фотография преподавателя» (Photo);
«Учетная запись преподавателя» (User);
«Коллекция тем дипломных проектов, предлагаемая преподавателем» (Thesis)
«Коллекция студентов, закрепленная за преподавателем»
(Student).
|
Листинг 24.5 – Класс «Преподаватель» |
|
|
|
|
1 |
namespace MyLib |
|
2 |
{ |
|
3 |
[Serializable] |
|
4 |
public partial class Professor |
|
5 |
{ |
|
6 |
public int Id { get; set; } |
|
7 |
public string Name { get; set; } |
|
8 |
public string Position { get; set; } |
|
9 |
public string PersonalData { get; set; } |
|
10 |
public byte[] Photo { get; set; } |
|
11 |
public virtual User User { get; set; } |
|
12 |
public virtual ICollection<Thesis> Thesis { get; set; } |
|
13 |
public virtual ICollection<Student> Student { get; set; } |
|
14 |
public Professor() |
|
15 |
{ |
|
16 |
this.Student = new List<Student>(); |
|
17 |
this.Thesis = new List<Thesis>(); |
|
18 |
} |
|
19 |
} |
|
20 |
} |
|
|
|
|
9
4. Класс CustomBinder, применяемый для десериализации объектов в другом проекте.
Класс BinaryFormatter, который используется для сериализации и десериализации в файл, сохраняет полное имя типа вместе с полным именем сборки (full qualified name). Соответственно если при десериализации форматтер не обнаруживает эту сборку, то генерируется исключение
SerializationException. Для того, чтобы десериализовать данные во втором проекте, необходимо подключить именно ту сборку, типы которой сериализовались ранее в первом проекте. Если таковой возможности нет, и вы сами гарантируете наличие аналогичных определений типов сериализованных объектов в другом проекте, то можно создать биндер, который переопределит имя сборки и типа во время десериализации и передаст нужную информацию форматтеру. Для этого достаточно определить наследника абстрактного класса System.Runtime.Serialization.SerializationBinder:
|
Листинг 24.6 – Класс CustomBinder |
|
|
|
|
1 |
namespace MyLib |
|
2 |
{ |
|
3 |
class CustomBinder : SerializationBinder |
|
4 |
{ |
|
5 |
public override Type BindToType |
|
(string assemblyName, string typeName) |
|
|
|
|
|
6 |
{ |
|
7 |
Assembly currentasm = Assembly.GetExecutingAssembly(); |
|
8 |
return Type.GetType($"{currentasm.GetName(). |
|
Name}.{typeName.Split('.')[1]}"); |
|
|
|
|
|
9 |
} |
|
10 |
} |
|
11 |
} |
|
Метод BindToType при переопределении в производном классе управляет привязкой сериализованного объекта к типу. Параметр assemblyName – это имя сборки сериализованного объекта, typename – имя типа сериализованного объекта. Данный метод возвращает тип объекта,
экземпляр которого создается модулем форматирования.
10