Данная статья не является призывом к экстремизму разработке велосипедов. Цель поста в том, чтобы хорошо понять механизм, зачастую его нужно создать с нуля. Особенно это касается такой зыбкой темы как ORM.
Зачем это все?
Промышленные продукты, такие как MS Entity Framework, NHibernate сложны, имеют огромный функционал и по сути представляют собой отдельную вещь в себе. Часто для получения нужного поведения от таких ORM, необходим отдельный человек, хорошо разбирающийся в тонкостях работы таких систем, что не есть хорошо в командной разработке.
Главный теоретический источник поста — книга Мартина Фаулера «Patterns of Enterprise Application Architecture (P of EAA)».
Существует куча информации о том что такое собственно ORM, DDD, TTD, ГИБДД — на этом я постараюсь не останавливаться, моя цель практическая. Предполагается две части статьи, в самым конце есть ссылка на полный исходный код в git hub.
Что мы хотим получить?
Сразу определимся с терминами: под трекингом будем понимать отслеживание изменений бизнес объектов в рамках одной транзакции, для дальнейшей синхронизации данных, хранящихся
в оперативной памяти и содержимого бд.
Какие же есть основные типы ORM?
- По использованию трекинга в .NET мире существует два типа ORM: с трекингом изменений и без трекинга изменений.
- Касательно подхода к генерации sql-запросов: с явным использованием запросов и на основе генераторов запросов из объектных моделей.
Например, среди известных ORM без трекинга и с явным использованием запросов, самый яркий пример — Dapper ORM от Stack Overflow. Основной функционал таких ORM заключается в маппинге реляционной модели бд к объектной модели, при этом клиент явно определяет как будет выглядеть его запрос к бд.
Основные концепции MS Entity Framework и NHibernate в использовании трекинга и генераторов запросов из объектных моделей. Не буду тут рассматривать преимущества и недостатки этих подходов. Все йогурты одинаково полезны и истина в комбинировании подходов.
Заказчик (то есть я) захотел создать ORM с использованием трекинга (с возможностью выключения) и на основе генераторов запросов из объектных моделей. Генерировать sql-запросы будем из лямбда — выражений языка C#, с нуля, без применения Linq2Sql, LinqToEntities (да, только хардкор!).
Из коробки, в MS Entity Framework есть неприятность с пакетным обновлением и удалением, данных: необходимо сначала достать все объекты из бд, далее в цикле обновитьудалить и затем применить изменения к бд. В итоге получаем больше обращений к бд, чем нужно. Проблема описана тут. Решим эту проблему во второй части статьи.
Определимся с основными ингредиентами
Сразу определимся каким образом клиентский код будет взаимодействовать с разрабатываемой библиотекой. Выделим основные компоненты ORM которые будут доступны из клиентского кода.
В основе концепции клиентского взаимодействия с ORM будет лежать идея наследования от абстрактного репозитория. Также необходимо определить суперкласс для ограничения множества бизнес объектов, с которыми будет работать ORM.
Каждый бизнес объект должен быть уникален в пределах своего типа, поэтому наследник должен явно переопределить свой идентификатор.
public abstract class Repository<T> : IRepository<T>
where T : EntityBase,new()
{
//Позже реализуем методы
}
//суперкласс бизнес объекта
public abstract class EntityBase : IEntity
{
//в потомках необходимо явно переопределить идентификатор
public abstract int Id { get; set; }
public object Clone()
{
return MemberwiseClone();
}
}Метод Clone() нам пригодится для копирования объекта, при трекинге, об этом будет чуть ниже.
Пусть у нас будет клиентский бизнес объект, хранящий информацию о пользователе — класс Profile.
Чтобы использовать бизнес объект в ORM необходимо три шага:
- Осуществить привязку бизнес объекта к таблице в базе данных на основе атрибутов
Класс Profile
//Все бизнес объекты должны быть наследниками суперкласса EntityBase [TableName("profile")] public class Profile : EntityBase { //Аргументом атрибута является точное название поля в бд [FieldName("profile_id")] public override int Id { get; } [FieldName("userinfo_id")] public int? UserInfoId { get; set; } [FieldName("role_id")] public int RoleId { get; set; } public string Info { get; set; } } - Определить репозиторий для каждого бизнес-объекта
Репозиторий профиля будет иметь вид
public class ProfileRepository : Repository<Profile> { //в качестве аргумента базовому классу передаем название строки подключения public ProfileRepository() : base("PhotoGallery") { //реализация клиентских CRUD методов } } - Сформировать строку подключения к бд
Строка подключения может выглядеть так
<connectionStrings> <add name="PhotoGallery" providerName="System.Data.SqlClient" connectionString="server=PCSQLEXPRESS; database=db_PhotoGallery"/> </connectionStrings>
Для трекинга изменений принято использовать паттерн UnitOfWork. Суть UnitOfWork в отслеживании действий, выполняемых над объектами домена, для дальнейшей синхронизации данных, хранящихся в оперативной памяти, с содержимым базы данных. При этом изменения фиксируются в один момент времени — все и сразу.
public interface IUnitOfWork : IDisposable
{
void Commit();
}
Казалось бы на этом все. Но нужно учесть два момента:
- Трекинг изменений должен обслуживать всю текущую бизнес транзакцию и должен быть доступен для всех бизнес объектов
- Бизнес-транзакция должна выполняться в рамках одного потока, поэтому нужно связать единицу работы с запущенным в данный момент потоком, используя локальное хранилище потока
Если с потоком бизнес-транзакции уже связан объект UnitOfWork, то его следует поместить именно в этот объект. Кроме того, с логической точки зрения единица работы принадлежит данному сеансу.
public static class Session
{
//локальное хранилище потока
private static readonly ThreadLocal<IUnitOfWork> CurrentThreadData =
new ThreadLocal<IUnitOfWork>(true);
public static IUnitOfWork Current
{
get { return CurrentThreadData.Value; }
private set { CurrentThreadData.Value = value; }
}
public static IUnitOfWork Create(IUnitOfWork uow)
{
return Current ?? (Current = uow);
}
}
Если необходимо обойтись без трекинга, то экземляр класса UnitOfWork создавать не нужно, ровно как и вызывать Session.Create.
Итак, после определения всех элементов, необходимых для взаимодействия с ORM, приведем пример работы с ORM.
var uow = new UnitOfWork();
using (Session.Create(uow))
{
var profileRepo = new ProfileRepository();
//Вызов методов репозитория
uow.Commit();
}
Приступаем к готовке
Все о чем мы говорили ранее касалось public части. Теперь рассмотрим internal часть. Для дальнейшей разработки необходимо определиться, что же из себя представляет структура объекта для трекинга.
Не стоит путать бизнес объект и объект для трекинга:
- Бизнес объект имеет свой тип, тогда как трекинг объект должен быть пригоден для массовых манипуляций над множеством бизнес объектов, то есть не должен зависеть от конкретного типа
- Трекинг объект есть сущность существующая в рамках конкретной бизнес транзакции, среди множества бизнес объектов, его уникальность должна определяться в рамках этой транзакции
Из чего следует, что такой объект должен обладать свойствами:
- Уникальным в пределах своего типа
- Неизменяемым
По сути объект для трекинга является контейнером для хранения бизнес объектов. Как отмечалось ранее, все клиентские бизнес-объекты должны быть предками суперкласса EntityBase и для них должен быть переопределен идентификатор объекта. Идентификатор обеспечивает уникальность в пределах типа, то есть таблицы в бд.
internal struct EntityStruct
{
//тип объекта
internal Type Key { get; private set; }
internal EntityBase Value { get; private set; }
internal EntityStruct(Type key, EntityBase value)
: this()
{
Key = key;
Value = value;
}
public override bool Equals(object obj)
{
return obj.GetHashCode() == GetHashCode();
}
public bool Equals(EntityBase obj)
{
return Equals(obj);
}
public override int GetHashCode()
{
//в пределах одной бд, тип объекта и идентификатор однозначно определяют его уникальность
var code = Key.GetHashCode() + Value.Id.GetHashCode();
//хэш код должен быть положительным числом
return code > 0 ? code : (-1) * code;
}
}
Трекинг бизнес объектов
Регистрация объектов для трекинга будет происходить на этапе получения этих объектов из репозитория.
После, получения бизнес объектов из бд, необходима их регистрация как объектов для трекинга.
Такие объекты имеют два состояния: сразу после получения из бд и после получения, до фиксации изменений.
Первые будем называть «чистыми», вторых «грязными» объектами.
var uow = new UnitOfWork();
using (Session.Create(uow))
{
var profileRepo = new ProfileRepository();
//регистрируем "чистые" объекты путем копирования полученных из бд,
//исходные считаем "грязными"
var profiles = profileRepo.Get(x=>x.Info = "Хороший юзер");
//изменяем "грязные" объекты
foreach (var profile in profiles)
{
profile.Info = "Плохой юзер";
}
//фиксация изменений
uow.Commit();
}
Важный момент заключается в том, что для сохранения «чистых» объектов необходимы операции копирования, что может губительно сказаться на производительности.
В общем случае регистрацию объектов трекинга необходимо проводить для каждого типа операций, таким образом должны быть объекты для операций обновления, удаления, вставки.
Нужно учесть что необходимо регистрировать только реально измененные объекты, для чего необходимы операции сравнения по значению (выше приведена реализация структуры EntityStruct с переопределенным методом Equals). В конечном счете операция сравнения, будет сведена к сравнению их хэшей.
События регистрации объектов трекинга будут возбуждаться из функционала абстрактного класса репозитория в его CRUD методах.
internal interface IObjectTracker
{
//для простоты приведен код регистрации только для измененных и новых объектов объектов
ICollection<EntityStruct> NewObjects { get; }
ICollection<EntityStruct> ChangeObjects { get; }
//методы регистрации
void RegInsertedNewObjects(object sender, AddObjInfoEventArgs e);
void RegCleanObjects(object sender, DirtyObjsInfoEventArgs e);
}
internal class DefaultObjectTracker : IObjectTracker
{
//ключ словаря - "грязный" объект, значение - "чистый" объект
private readonly Dictionary<EntityStruct, EntityStruct> _dirtyCreanPairs;
public ICollection<EntityStruct> NewObjects { get; private set; }
public ICollection<EntityStruct> ChangeObjects
{
get
{
// получаем измененные объекты
return _dirtyCreanPairs.GetChangesObjects();
}
}
internal DefaultObjectTracker()
{
NewObjects = new Collection<EntityStruct>();
//Чтобы избежать лишних boxing/unboxing операций реализуем свой EqualityComparer
_dirtyCreanPairs =
new Dictionary<EntityStruct, EntityStruct>(new IdentityMapEqualityComparer());
}
public void RegInsertedNewObjects(object sender, AddObjInfoEventArgs e)
{
NewObjects.Add(e.InsertedObj);
}
public void RegCleanObjects(object sender, DirtyObjsInfoEventArgs e)
{
var objs = e.DirtyObjs;
foreach (var obj in objs)
{
if (!_dirtyCreanPairs.ContainsKey(obj))
{
//получаем "чистый" объект путем клонирования исходного при помощи MemberwiseClone()
var cloneObj = new EntityStruct(obj.Key, (EntityBase)obj.Value.Clone());
_dirtyCreanPairs.Add(obj, cloneObj);
}
}
}
} public static ICollection<EntityStruct> GetChangesObjects
(
this Dictionary<EntityStruct, EntityStruct> dirtyCleanPairs
)
{
var result = new List<EntityStruct>();
foreach (var cleanObj in dirtyCleanPairs.Keys)
{
if (!(cleanObj.Key == dirtyCleanPairs[cleanObj].Key))
{
throw new Exception("incorrect types");
}
if (ChangeDirtyObjs(cleanObj.Value, dirtyCleanPairs[cleanObj].Value, cleanObj.Key))
{
result.Add(cleanObj);
}
}
return result;
}
public static bool ChangeDirtyObjs(EntityBase cleanObj, EntityBase dirtyObj, Type type)
{
var props = type.GetProperties();
//цикл по каждому свойству объекта
foreach (var prop in props)
{
var cleanValue = prop.GetValue(cleanObj, null);
var dirtyValue = prop.GetValue(dirtyObj, null);
//если хоть одно свойство изменено, считаем объект пригодным для регистрации
if (!cleanValue.Equals(dirtyValue))
{
return true;
}
}
return false;
}
Необходимо учесть, что бизнес объекты одной транзакции могут быть из разных бд. Логично предположить что для каждой бд должен быть определен свой экземпляр трекинга (класса, реализующего IObjectTracker, например DefaultObjectTracker).
Текущей транзакции нужно заранее «знать» из для каких бд будет выполнен трекинг. На этапе создания экземпляра UnitOfWork, необходимо инициализировать экземпляры объектов трекинга (экземпляр класса DefaultObjectTracker) по указанным подключениям к бд в конфигурационном файле.
internal interface IDetector
{
//ключ слова - строка подключения к базу, значение - объект трекинга
Dictionary<string, IObjectTracker> ObjectDetector { get; }
}
public sealed class UnitOfWork : IUnitOfWork, IDetector
{
private readonly Dictionary<string, IObjectTracker> _objectDetector;
Dictionary<string, IObjectTracker> IDetector.ObjectDetector
{
get { return _objectDetector; }
}
public UnitOfWork()
{
_objectDetector = new Dictionary<string, IObjectTracker>();
foreach (ConnectionStringSettings conName in ConfigurationManager.ConnectionStrings)
{
//каждому подключению к базе соответствует свой экземпляр трекинга
_objectDetector.Add(conName.Name, new DefaultObjectTracker());
}
}
}
Информация о том какой экземпляр трекинга какой базе будет соответствовать должна быть доступна всем экземплярам репозитория в рамках транзакции. Удобно создать единую точку доступа в статическом классе Session.
public static class Session
{
private static readonly ThreadLocal<IUnitOfWork> CurrentThreadData = new ThreadLocal<IUnitOfWork>(true);
public static IUnitOfWork Current
{
get { return CurrentThreadData.Value; }
private set { CurrentThreadData.Value = value; }
}
public static IUnitOfWork Create(IUnitOfWork uow)
{
return Current ?? (Current = uow);
}
//Метод возвращает нужный экземляр трекинга для текущей транзакции
// по имени строки подключения
internal static IObjectTracker GetObjectTracker(string connectionName)
{
var uow = Current;
if (uow == null)
{
throw new ApplicationException(" Create unit of work context and using Session.");
}
var detector = uow as IDetector;
if (detector == null)
{
throw new ApplicationException("Create unit of work context and using Session.");
}
return detector.ObjectDetector[connectionName];
}
}
}
Доступ к данным
Функционал доступа к данным будет непосредственно вызывать методы обращения к бд. Этот функционал будет использоваться классом абстрактного репозитория в его CRUD методах. В простом случае класс доступа к данным включает в себя CRUD методы для работы с данными.
internal interface IDataSourceProvider : IDisposable
{
State State { get; }
//для простоты фиксировать изменения в бд, будем только для измененных объектов
void Commit(ICollection<EntityStruct> updObjs);
ICollection<T> GetByFields<T>(BinaryExpression exp) where T : EntityBase, new();
}
internal class DbProvider : IDataSourceProvider
{
private IDbConnection _connection;
internal DbProvider(IDbConnection connection)
{
_connection = connection;
State = State.Open;
}
public State State { get; private set; }
public ICollection<T> GetByFields<T>(BinaryExpression exp) where T : EntityBase, new()
{
// делегат возвращающий текст select-запроса по выражению exp
Func<IDbCommand, BinaryExpression, string> cmdBuilder = SelectCommandBulder.Create<T>;
ICollection<T> result;
using (var conn = _connection)
{
using (var command = conn.CreateCommand())
{
command.CommandText = cmdBuilder.Invoke(command, exp);
command.CommandType = CommandType.Text;
conn.Open();
result = command.ExecuteListReader<T>();
}
}
State = State.Close;
return result;
}
public void Commit(ICollection<EntityStruct> updObjs)
{
if (updObjs.Count == 0)
{
return;
}
// ключ - делегат возвращающий текст update-запроса по выражению exp
//значение - измененные объекты
var cmdBuilder = new Dictionary<Func<IDbCommand, ICollection<EntityStruct>, string>, ICollection<EntityStruct>>();
cmdBuilder.Add(UpdateCommandBuilder.Create, updObjs);
ExecuteNonQuery(cmdBuilder, packUpdDict, packDeleteDict);
}
private void ExecuteNonQuery(Dictionary<Func<IDbCommand, ICollection<EntityStruct>, string>, ICollection<EntityStruct>> cmdBuilder)
{
using (var conn = _connection)
{
using (var command = conn.CreateCommand())
{
var cmdTxtBuilder = new StringBuilder();
foreach (var builder in cmdBuilder)
{
cmdTxtBuilder.Append(builder.Key.Invoke(command, builder.Value));
}
command.CommandText = cmdTxtBuilder.ToString();
command.CommandType = CommandType.Text;
conn.Open();
if (command.ExecuteNonQuery() < 1)
throw new ExecuteQueryException(command);
}
}
State = State.Close;
}
private ICollection<T> ExecuteListReader<T>(EntityStruct objs)
where T : EntityBase, IEntity, new()
{
Func<IDbCommand, EntityStruct, string> cmdBuilder = SelectCommandBulder.Create;
ICollection<T> result;
using (var conn = _connection)
{
using (var command = conn.CreateCommand())
{
command.CommandText = cmdBuilder.Invoke(command, objs);
command.CommandType = CommandType.Text;
conn.Open();
result = command.ExecuteListReader<T>();
}
}
State = State.Close;
return result;
}
private void Dispose()
{
if (State == State.Open)
{
_connection.Close();
State = State.Close;
}
_connection = null;
GC.SuppressFinalize(this);
}
void IDisposable.Dispose()
{
Dispose();
}
~DbProvider()
{
Dispose();
}
}
Классу DbProvider необходимо существующее соединение с бд. Делегируем создание соединения и дополнительной инфраструктуры отдельному классу на основе фабричного метода. Таким образом создавать экземпляры класса DbProvider необходимо только через вспомогательный класс фабрики.
class DataSourceProviderFactory
{
static DbConnection CreateDbConnection(string connectionString, string providerName)
{
if (string.IsNullOrWhiteSpace(connectionString))
{
throw new ArgumentException("connectionString is null or whitespace");
}
DbConnection connection;
DbProviderFactory factory;
try
{
factory = DbProviderFactories.GetFactory(providerName);
connection = factory.CreateConnection();
if (connection != null) connection.ConnectionString = connectionString;
}
catch (ArgumentException)
{
try
{
factory = DbProviderFactories.GetFactory("System.Data.SqlClient");
connection = factory.CreateConnection();
if (connection != null)
{
connection.ConnectionString = connectionString;
}
}
catch (Exception)
{
throw new Exception("DB connection has been failed.");
}
}
return connection;
}
public static IDataSourceProvider Create(string connectionString)
{
var settings = ConfigurationManager.ConnectionStrings[connectionString];
var dbConn = CreateDbConnection(settings.ConnectionString, settings.ProviderName);
return new DbProvider(dbConn);
}
public static IDataSourceProvider CreateByDefaultDataProvider(string connectionString)
{
var dbConn = CreateDbConnection(connectionString, string.Empty);
return new DbProvider(dbConn);
}
}
Регистрация трекинг объектов должна происходить в CRUD методах репозитория, тот в свою очередь делегирует функционал слою доступа к данным. Таким образом необходима реализация интерфейса IDataSourceProvider с учетом трекинга. Регистрировать объекты будем на основе механизма событий, которые будут возбуждаться именно в этом классе. Предполагаемая новая реализация интерфейса IDataSourceProvider должна «уметь» как инициализировать события регистрации на трекинг, так и обращаться к бд. В данном случае удобно декорировать класс DbProvider.
internal class TrackerProvider : IDataSourceProvider
{
private event EventHandler<DirtyObjsInfoEventArgs> DirtyObjEvent;
private event EventHandler<UpdateObjsInfoEventArgs> UpdateObjEvent;
private readonly IDataSourceProvider _dataSourceProvider;
private readonly string _connectionName;
private readonly object _syncObj = new object();
private IObjectTracker ObjectTracker
{
get
{
lock (_syncObj)
{
// получаем необходимый экземпляр трекинга
return Session.GetObjectTracker(_connectionName);
}
}
}
public TrackerProvider(string connectionName)
{
_connectionName = connectionName;
_dataSourceProvider = DataSourceProviderFactory.Create(_connectionName);
// регистрация событий трекинга
RegisterEvents();
}
public State State
{
get
{
return _dataSourceProvider.State;
}
}
private void RegisterEvents()
{
//Использование класса корректно только при использовании трекинга
if (Session.Current == null)
{
throw new ApplicationException("Session has should be used. Create a session.");
};
//подписка на события трекинга
DirtyObjEvent += ObjectTracker.RegCleanObjects;
UpdateObjEvent += ObjectTracker.RegUpdatedObjects;
}
public ICollection<T> GetByFields<T>(BinaryExpression exp)
where T : EntityBase, IEntity, new()
{
//получаем исходные объекты из бд посредством экземпляра класса DbProvider
var result = _dataSourceProvider.GetByFields<T>(exp);
var registratedObjs = result.Select(r => new EntityStruct(typeof(T), r)).ToList();
//Возбуждаем событие регистрации "грязных" объектов
var handler = DirtyObjEvent;
if (handler == null)
return result;
handler(this, new DirtyObjsInfoEventArgs(registratedObjs));
return result;
}
public void Commit(ICollection<EntityStruct> updObjs)
{
//полностью делегируем выполнение экземпляру класса DbProvider
_dataSourceProvider.Commit(updObjs, delObjs, addObjs, packUpdObjs, deleteUpdObjs);
}
public void Dispose()
{
_dataSourceProvider.Dispose();
}
}
Промежуточные итоги
Разберемся каким образом теперь будут выглядеть наши public-классы.
Как отмечалось чуть выше, класс репозитория должен делегировать свою функциональность реализациям интерфейса IDataSourceProvider'а. При инициализации класса репозитория, на основе переданной в конструктор строки подключения, необходимо создать нужную реализацию IDataSourceProvider'а в зависимости от использования трекинга. Также необходимо учесть, что класс доступа к данным может в любой момент времени «потерять» соединение с бд, для чего с помощью свойства будем следить за этим соединением.
Класс UnitOfWork'а, как уже отмечалось ранее, в своем конструкторе должен создать список объектов класса DefaultObjectTracker по всем доступным в строке подключения бд. Логично, что фиксация изменений должна также происходить по всем бд: для каждого экземпляра трекинга будет вызываться метод фиксации его изменений.
public abstract class Repository<T> : IRepository<T>
where T : EntityBase, IEntity, new()
{
private readonly object _syncObj = new object();
private IDataSourceProvider _dataSourceProvider;
//c помощью свойства "мониторим" соединение с бд
private IDataSourceProvider DataSourceProvider
{
get
{
lock (_syncObj)
{
if (_dataSourceProvider.State == State.Close)
{
_dataSourceProvider = GetDataSourceProvider();
}
return _dataSourceProvider;
}
}
}
private readonly string _connectionName;
protected Repository(string connectionName)
{
if (string.IsNullOrWhiteSpace(connectionName))
{
throw new ArgumentNullException("connectionName");
}
_connectionName = connectionName;
var dataSourceProvider = GetDataSourceProvider();
if (dataSourceProvider == null)
{
throw new ArgumentNullException("dataSourceProvider");
}
_dataSourceProvider = dataSourceProvider;
}
private IDataSourceProvider GetDataSourceProvider()
{
//если трекинг включен создаем экземпляр класса DbProvider'а
// иначе создаем его ////декорированную версию - TrackerProvider
return Session.Current == null ? DataSourceProviderFactory.Create(_connectionName)
: new TrackerProvider(_connectionName);
}
public ICollection<T> Get(Expression<Func<T, bool>> exp)
{
return DataSourceProvider.GetByFields<T>(exp.Body as BinaryExpression);
}
}
public sealed class UnitOfWork : IUnitOfWork, IDetector
{
private readonly Dictionary<string, IObjectTracker> _objectDetector;
Dictionary<string, IObjectTracker> IDetector.ObjectDetector
{
get { return _objectDetector; }
}
public UnitOfWork()
{
_objectDetector = new Dictionary<string, IObjectTracker>();
foreach (ConnectionStringSettings conName in ConfigurationManager.ConnectionStrings)
{
_objectDetector.Add(conName.Name, new DefaultObjectTracker());
}
}
public void Commit()
{
SaveChanges();
}
private async void SaveChanges()
{
await Task.Run(() =>
{
//фиксируем изменения в экземплярах трекинга по каждой из бд
foreach (var objectDetector in _objectDetector)
{
var provider = new TrackerProvider(objectDetector.Key);
provider.Commit(
objectDetector.Value.ChangeObjects);
}
}
);
}
}
В продолжении статьи рассмотрю работу со связанными сущностями, генерацию sql запросов на основе деревьев выражений, методы пакетного удаления/изменения данных (по типу UpdateWhere, RemoveWhere).
Полностью весь исходный код проекта, без упрощений, лежит тут.
Автор: eddHunter
