ООП, модель данных и база данных

@OttoFix · Регистрация: 11.12.2018

Студворк — интернет-сервис помощи студентам

Начитался я умных книжек, статей и прочего, в результате в голове полный «компот»

Надеюсь сможете мне растравить все на свои места.

В общем, у меня есть несколько небольших программ которые производят в основном обработку / конвертацию данных в формат понятный для одной коммерческой программы.
С недавнего времени встала необходимость использования в них базы данных. Я выбрал firebird 3, а так же сами программы решил переписать на C#. До этого немного работал с C# .net в основном получалась гремучая смесь ООП и процедурно — функционального программирования.
Допустим у нас есть некая база, по ней мы создаем модель данных, в результате у нас получается несколько классов описания модели. Так же нам необходимо создать класс так сказать посредник между провайдером данных и нашей моделью и тут у меня возникают трудности (в основном боязнь создать «божественный» класс). Класс посредника я представляю так, он должен принимать SQL команду (SQL процедуру, функцию и.д.) и ссылку на объект нашей модели, результатом выполнения должна быть заполненная модель данных или её часть. Вот не могу понять, как правильно связать dataadapter и модель, возможно dataadapter вообще лишнее звено и от него надо избавится, а взамен реализовать свой IDataReader.
За dataadapter я держусь из-за того, что уже привык к удобству работать в отключенном режиме, легкому применению изменений, к статусам и версиям строк, и т.д.. Если без него, то отключенный режим необходимо будет реализовать в модели (версии и статусы данных), а так же динамическую подгрузку данных? Но опять же с dataadapter необходимо как-то из DataTables данные перемещать в модель, циклами как-то накладно получается или есть способ лучше?

ADO.NET Entity Framewrok — не рассматриваю, да его использование почти все мои вопросы сведет на нет, но это такой жирный «монстр», что для меня его использование перебор, плюс его долгая работа с запросами, да вообще мне SQL синтаксис больше по душе.

Присматриваюсь к Dapper (как я понял он как раз реализует свой интерфейс IDataReader), возможно он и будет моим спасением, но все же хотелось бы узнать, как все таки работать с моделью данных и чистым ADO.NET.

Буду очень благодарен за любое разъяснение или примеры кода.

@Usaga · 28.12.2018, 09:47

Сообщение от OttoFix

Допустим у нас есть некая база, по ней мы создаем модель данных, в результате у нас получается несколько классов описания модели.

Модель данных построенная по схеме базы, как правило, эту схему отражает в соотношении один к одному. Такая модель является набором структур хранения. В небольших проектах допустимо трактовать эту модель и моделью данных \ бизнес-логики, ибо на малых масштабах городить абстракции не практично. Но вещи это разные, это нужно понимать.

Сообщение от OttoFix

и. Так же нам необходимо создать класс так сказать посредник между провайдером данных и нашей моделью

Да. Имя этому посреднику - репозиторий. Репозиторий - сервис-обёртка над технологией хранения (СУБД, веб-сервис, файлы, ОЗУ) предоставляющий набор методов для операций CRUD (create, read, update, delete) и полностью скрывающий все моменты используемого хранилища. Обмен с этим сервисом идёт посредствам модели данных, бизнес-моделей и DTO. Хотя, если есть острая необходимость, то можно и DataTable использовать.

Поищите примеры этого паттерна (репозиторий). Вам чаще всего будут попадаться примеры на основе Entity Framework, но это из-за популярности данной ORM. Сам паттерн применим к любому механизму работы с хранилищем. Включая голый ADO.NET, Dapper или вообще WebClient.

Сообщение от OttoFix

ADO.NET Entity Framewrok — не рассматриваю, да его использование почти все мои вопросы сведет на нет, но это такой жирный «монстр», что для меня его использование перебор, плюс его долгая работа с запросами, да вообще мне SQL синтаксис больше по душе.

Жирнота этой ORM проявляется только на контекстах конского размера (500+ сущностей). И то выражается в долгом разогреве при запуске приложения. Запросы он отрабатывает быстро. Просто не надо девятиэтажку строить из Include'ов. Просто попробуйте такой же девятиэтажный запрос на голом SQL построить. Поверьте, он не будет работать ни быстрее, ни выглядеть компактнее не будет.

@OttoFix · 28.12.2018, 10:18 **[ТС]**

Сообщение от Usaga

Такая модель является набором структур хранения.

Именно это я имел ввиду, просто не стал описывать, что будет класс реализующий некие действия с данными из модели (бизнес логика). У меня в основном бизнес логика построена на процедурах и функциях в базе SQL, для меня это был осознанный выбор.

Сообщение от Usaga

Поищите примеры этого паттерна (репозиторий).

Спасибо, поизучаем этот момент, я как-то обходил стороной темы про репозиторий (проводил аналогию с linux, там тоже есть репозитории программ) и думал мне это не нужно.

Сообщение от Usaga

Вам чаще всего будут попадаться примеры на основе Entity Framework

Да, так оно и есть, складывается ощущение, что модель данных появилась только с ORM (поэтому и запутался).

Не по теме:

Спасибо, что осилили мои много буков :D

@Usaga · 28.12.2018, 10:54

Сообщение от OttoFix

складывается ощущение, что модель данных появилась только с ORM

Идеология EF'а - косить под бизнес-модель приложения. И он это делает очень успешно. Что и приводит к путанице. Люди реально воспринимают сущности EF'а как бизнес-модель и что их не отличить.

@OttoFix · 29.12.2018, 06:18 **[ТС]**

И так, вроде бы все встает на свои места, после прочтения про паттерны Repository и Unit of work.
В результате, на текущий момент мне придется отказаться от идеи использовать модель данных в виду того, что у меня на текущий момент бизнес логика находится в базе данных, а репозиторий должен оперировать так сказать "сырыми" данными из базы, а не готовыми выборками из процедур.

Но для закрепления материала попробую создать тестовое приложение с базой из 3-5 таблиц, моделью данных и бизнес логикой.
Я правильно понимаю, для построения приложения по такому описанию, база должна содержать только сущности и логику целостности данных?

@Usaga · 29.12.2018, 06:49

Сообщение от OttoFix

а репозиторий должен оперировать так сказать "сырыми" данными из базы, а не готовыми выборками из процедур.

Да? С чего бы это вдруг?

Сообщение от OttoFix

Я правильно понимаю, для построения приложения по такому описанию, база должна содержать только сущности и логику целостности данных?

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

@OttoFix · 29.12.2018, 07:21 **[ТС]**

Сообщение от Usaga

Да? С чего бы это вдруг?

К примеру, интерфейс репозитория "продукты" (в базе данных есть таблица Products) выглядит так

C#
1
2
3
4
5
6
7
8
9
10
interface IRepository<T> : IDisposable 
        where T : class
{
    IEnumerable<T> GetProductList(); // получение всех объектов продукт
    T GetProduct(int id); // получение одного объекта по id
    void Create(T item); // создание объекта
    void Update(T item); // обновление объекта
    void Delete(int id); // удаление объекта по id
    void Commit();  // сохранение изменений
}

Если логика в базе SQL (построена на процедурах и функциях), то нам данные из этой таблицы в чистом виде не нужны, но данные из нее присутствуют в результирующих выборках некой процедуры. И как можно создать репозиторий для процедуры, результатом которой является некое объединение трех таблиц? Разве это не будет нарушением?

Сообщение от Usaga

База может содержать что угодно. Репозиториям до фонаря.

Это я понимаю, но база тоже должна быть спроектирована под определенные концепции, я про это.

@Usaga · 29.12.2018, 07:39

Сообщение от OttoFix

Если логика в базе SQL (построена на процедурах и функциях), то нам данные из этой таблицы в чистом виде не нужны, но данные из нее присутствуют в результирующих выборках некой процедуры. И как можно создать репозиторий для процедуры, результатом которой является некое объединение трех таблиц? Разве это не будет нарушением?

Нарушением чего? Вам приходит выборка (не важно, чистым SQL'ом сформированная или полученная от процедуры). Вы её мапите на класс. Что здесь чему противоречит и что нарушается? Я же русским языком сказал, что источник данных для репозитория роли не играет. А уж что данные формирует - чистый SQL или процедура - подавно плевать.

Сообщение от OttoFix

Это я понимаю, но база тоже должна быть спроектирована под определенные концепции, я про это.

Ну так и проектируйте её так, как вам надо. Репозитории вам тут не помешают ничем. Они лишь выступают адаптерами между хранилищем и бизнес-логикой.

@Tessio · 29.12.2018, 07:50

Сообщение от OttoFix

Разве это не будет нарушением?

Нарушением чего? Репозиторий - это абстракция, пользователям репозитория, совершенно не важно что там происходит в методах, им необходимо либо получить данные, либо их отдать для добавления, изменения или удаления. А для репозитория всё равно как источник данных отдаёт данные, через запросы или процедуры.

Сообщение от OttoFix

придется отказаться от идеи использовать модель данных

А вот это совершенно неверный подход.

@OttoFix · 29.12.2018, 08:51 **[ТС]**

Сообщение от Usaga

Нарушением чего?

Это я уже про разделение слоев база данных - бизнес логика - и.д. (извиняюсь в путанице).

Сообщение от Usaga

Вы её мапите на класс.

В моем случае, это будет лишним телодвижением, так как выборка уже готовый результат, который необходимо только отобразить пользователю.

Естественно полного просветления за несколько часов я не получил, но хотя бы начал улавливать суть.
На практике думаю понимание придет лучше, поэтому начну понемногу разрабатывать тестовый проект.

Как на Ваш взгляд, репозиторий должен быть один или для каждой сущности свой? Просто везде пишут по-разному.

Еще раз спасибо за разъяснения.

Добавлено через 5 минут

Сообщение от Tessio

А вот это совершенно неверный подход.

Возможно, но очень не хочется переделывать базу. Из программы нет ни одного инсерта, апдейта или селекта, все идет через процедуры, на них есть свои ограничения в правах. Таким образом программа только выполняет роль удобного вьювера и удобного запуска процедур обработки.

Добавлено через 19 минут
Добавлю, что бы Вы не подумали, что Ваши советы были напрасны.
Я естественно продолжу дальше разбираться с этим вопросом, но это требует времени.
А проект я не могу "заморозить" на неопределенный срок, поэтому я его доделаю с текущей базой и работой с dataadepter.

@Usaga · 29.12.2018, 08:57

Сообщение от OttoFix

Это я уже про разделение слоев база данных - бизнес логика - и.д. (извиняюсь в путанице).

Какие слои ещё? Репозиторию на это наплевать. У него есть интерфейс общения с СУБД, через который он и получает данные. А какие там слои в СУБД - это аспект самой СУБД и за её пределы не выходит.

Сообщение от OttoFix

В моем случае, это будет лишним телодвижением, так как выборка уже готовый результат, который необходимо только отобразить пользователю.

Нет, не лишним. Вы мапите представление данных полученное из хранилища (DataTable, SqlDataAdapter, SqlDataReader) в то, с чем удобно работать бизнес-логике. Ну и обратно.

Сообщение от OttoFix

Как на Ваш взгляд, репозиторий должен быть один или для каждой сущности свой? Просто везде пишут по-разному.

Репозиторий на агрегат.

Сообщение от OttoFix

Возможно, но очень не хочется переделывать базу.

Её не надо переделывать. Переделкой занимается репозиторий. На ходу.

@OttoFix · 29.12.2018, 09:02 **[ТС]**

Сообщение от Usaga

с чем удобно работать бизнес-логике

В программе её нет, поэтому программе достаточно только SqlDataAdapter, DataTable.

@Usaga · 29.12.2018, 09:18

OttoFix, это не так. Даже малейший намёк на валидацию или какой-нибудь 2+2 - уже бизнес логика. Даже байндинги (если есть) удобнее применять над нормальным типизированным представлением данных.

@OttoFix · 29.12.2018, 09:36 **[ТС]**

Сообщение от Usaga

Даже малейший намёк на валидацию или какой-нибудь 2+2 - уже бизнес логика.

Согласен, есть некоторые моменты из бизнес-логики и в коде, но их минимум.
Я не оспариваю Ваши разъяснения, просто на текущий момент у меня не достаточно познаний в этом, что бы быстро смог реализовать.
Поэтому, надеюсь Вы сможете мне еще помочь, но уже на конкретном моем тестовом проекте.

@Usaga · 29.12.2018, 09:41

Сообщение от OttoFix

Поэтому, надеюсь Вы сможете мне еще помочь, но уже на конкретном моем тестовом проекте.

Не нужны никакие проекты. Сами посмотрите на два подхода:

C#
1
2
3
4
5
public class User
{
    public string Name { get; set; }
    public int Age { get; set; }
}

C#
1
DataTable;

Оба представляют сущность "Пользователь". Какой из вариантов удобнее и нагляднее?

@Cupko · 29.12.2018, 11:21

Не по теме:

Смешались в кучу, кони, люди

Если речь идет о Database-centric архитектуре, где вся логика в хранимках, то Repository тут не нужен. Его даже физически прикрутить сложно будет.
Смотрите на Data Mapper паттерн.
Dapper может помочь вам (я с ним не работал, но наслышан).
В свое время в подобном проекте использовали BlToolkit и Active record ~~анти~~паттерн. Все живы, проект жив.

@Usaga · 29.12.2018, 11:29

Сообщение от Cupko

то Repository тут не нужен. Его даже физически прикрутить сложно будет.

Это как это так?

@Cupko · 29.12.2018, 12:30

Сообщение от Usaga

Это как это так?

Я сначала написал "невозможно", но быстро осознал, что если очень хочется...

Репозиторий - он все же есть подобие коллекции для доменных объектов. И очень сложно представить коллекцию, когда у тебя есть хранимка возвращающая одну запись, но нет хранимки для нескольких, для поиска, для Edit/Update/Delete. Получается уж очень как-то кривовато.

Нет, вы можете назвать свои DAL объекты репозиторием, но от этого они репозиториями не станут.

@Usaga · 29.12.2018, 15:51

Cupko, репозиторий не подобие коллекции. Это абстракция над хранилищем, которая предоставляет методы по работе с этим хранилищем: добавлением, удалением, поиском записей. В этом плане хранимая процедура вообще ничего не меняет. Вообще. Хотите в виде хранимых процедур организовывать своё хранилище? Да пожалуйста! Репозиторий менее полезным от этого не станет.

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

@Cupko · 29.12.2018, 16:07

Usaga, вы мой пост вообще читали?

Сообщение от M. Fowler

Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.

И это как бы автор этого паттерна.

Сообщение от Usaga

которые преимущественно занимаются мапингом.

Это и есть Data Mapper.

Сообщение от Usaga

Понадобился какой-то метод, который хранимками не реализован? Ну так напишите ещё одну хранимку.

А если этот метод с точки зрения бизнес-логики не нужен? Получается явная проблема дизайна.

Я не исключаю теоретической возможности работы с хранимками и репозиторием. Я говорю об его неуместности в Database-centric архитектуре.

Новые блоги и статьи Все статьи Все блоги /
Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331

	ООП, модель данных и база данных 28.12.2018, 08:57. Показов 5006. Ответов 21 Метки ado.net, dapper (Все метки) Начитался я умных книжек, статей и прочего, в результате в голове полный «компот» Надеюсь сможете мне растравить все на свои места. В общем, у меня есть несколько небольших программ которые производят в основном обработку / конвертацию данных в формат понятный для одной коммерческой программы. С недавнего времени встала необходимость использования в них базы данных. Я выбрал firebird 3, а так же сами программы решил переписать на C#. До этого немного работал с C# .net в основном получалась гремучая смесь ООП и процедурно — функционального программирования. Допустим у нас есть некая база, по ней мы создаем модель данных, в результате у нас получается несколько классов описания модели. Так же нам необходимо создать класс так сказать посредник между провайдером данных и нашей моделью и тут у меня возникают трудности (в основном боязнь создать «божественный» класс). Класс посредника я представляю так, он должен принимать SQL команду (SQL процедуру, функцию и.д.) и ссылку на объект нашей модели, результатом выполнения должна быть заполненная модель данных или её часть. Вот не могу понять, как правильно связать dataadapter и модель, возможно dataadapter вообще лишнее звено и от него надо избавится, а взамен реализовать свой IDataReader. За dataadapter я держусь из-за того, что уже привык к удобству работать в отключенном режиме, легкому применению изменений, к статусам и версиям строк, и т.д.. Если без него, то отключенный режим необходимо будет реализовать в модели (версии и статусы данных), а так же динамическую подгрузку данных? Но опять же с dataadapter необходимо как-то из DataTables данные перемещать в модель, циклами как-то накладно получается или есть способ лучше? ADO.NET Entity Framewrok — не рассматриваю, да его использование почти все мои вопросы сведет на нет, но это такой жирный «монстр», что для меня его использование перебор, плюс его долгая работа с запросами, да вообще мне SQL синтаксис больше по душе. Присматриваюсь к Dapper (как я понял он как раз реализует свой интерфейс IDataReader), возможно он и будет моим спасением, но все же хотелось бы узнать, как все таки работать с моделью данных и чистым ADO.NET. Буду очень благодарен за любое разъяснение или примеры кода. 0

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331
	29.12.2018, 06:18 [ТС]
	И так, вроде бы все встает на свои места, после прочтения про паттерны Repository и Unit of work. В результате, на текущий момент мне придется отказаться от идеи использовать модель данных в виду того, что у меня на текущий момент бизнес логика находится в базе данных, а репозиторий должен оперировать так сказать "сырыми" данными из базы, а не готовыми выборками из процедур. Но для закрепления материала попробую создать тестовое приложение с базой из 3-5 таблиц, моделью данных и бизнес логикой. Я правильно понимаю, для построения приложения по такому описанию, база должна содержать только сущности и логику целостности данных? 0

@Usaga 14073 / 9290 / 1347 Регистрация: 21.01.2016 Сообщений: 34,877
	29.12.2018, 09:18
	OttoFix, это не так. Даже малейший намёк на валидацию или какой-нибудь 2+2 - уже бизнес логика. Даже байндинги (если есть) удобнее применять над нормальным типизированным представлением данных. 0

@Cupko 654 / 591 / 171 Регистрация: 17.07.2012 Сообщений: 1,680 Записей в блоге: 1
	29.12.2018, 11:21
	Не по теме: Смешались в кучу, кони, люди Если речь идет о Database-centric архитектуре, где вся логика в хранимках, то Repository тут не нужен. Его даже физически прикрутить сложно будет. Смотрите на Data Mapper паттерн. Dapper может помочь вам (я с ним не работал, но наслышан). В свое время в подобном проекте использовали BlToolkit и Active record ~~анти~~паттерн. Все живы, проект жив. 1

@Usaga 14073 / 9290 / 1347 Регистрация: 21.01.2016 Сообщений: 34,877
	29.12.2018, 15:51
	Cupko, репозиторий не подобие коллекции. Это абстракция над хранилищем, которая предоставляет методы по работе с этим хранилищем: добавлением, удалением, поиском записей. В этом плане хранимая процедура вообще ничего не меняет. Вообще. Хотите в виде хранимых процедур организовывать своё хранилище? Да пожалуйста! Репозиторий менее полезным от этого не станет. Пара наших старых проектов по такой схеме и построены. В базе только хранимки, а над ними репозитории, которые преимущественно занимаются мапингом. Никаких противоречий ни в чём нет. Понадобился какой-то метод, который хранимками не реализован? Ну так напишите ещё одну хранимку. 0

ООП, модель данных и база данных

Решение