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

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

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

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

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

В общем, у меня есть несколько небольших программ которые производят в основном обработку / конвертацию данных в формат понятный для одной коммерческой программы.
С недавнего времени встала необходимость использования в них базы данных. Я выбрал 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#

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#

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 архитектуре.

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

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331
	29.12.2018, 09:36 [ТС]	14
	Сообщение от Usaga Даже малейший намёк на валидацию или какой-нибудь 2+2 - уже бизнес логика. Согласен, есть некоторые моменты из бизнес-логики и в коде, но их минимум. Я не оспариваю Ваши разъяснения, просто на текущий момент у меня не достаточно познаний в этом, что бы быстро смог реализовать. Поэтому, надеюсь Вы сможете мне еще помочь, но уже на конкретном моем тестовом проекте. 0

@Usaga 12078 / 8387 / 1281 Регистрация: 21.01.2016 Сообщений: 31,595
	29.12.2018, 11:29	17
	Сообщение от Cupko то Repository тут не нужен. Его даже физически прикрутить сложно будет. Это как это так? 0

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331
		1
	ООП, модель данных и база данных 28.12.2018, 08:57. Показов 4364. Ответов 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

@Usaga 12078 / 8387 / 1281 Регистрация: 21.01.2016 Сообщений: 31,595
	28.12.2018, 09:47	2
	Сообщение было отмечено OttoFix как решение Решение Сообщение от 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 построить. Поверьте, он не будет работать ни быстрее, ни выглядеть компактнее не будет. 2

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331
	28.12.2018, 10:18 [ТС]	3
	Сообщение от Usaga Такая модель является набором структур хранения. Именно это я имел ввиду, просто не стал описывать, что будет класс реализующий некие действия с данными из модели (бизнес логика). У меня в основном бизнес логика построена на процедурах и функциях в базе SQL, для меня это был осознанный выбор. Сообщение от Usaga Поищите примеры этого паттерна (репозиторий). Спасибо, поизучаем этот момент, я как-то обходил стороной темы про репозиторий (проводил аналогию с linux, там тоже есть репозитории программ) и думал мне это не нужно. Сообщение от Usaga Вам чаще всего будут попадаться примеры на основе Entity Framework Да, так оно и есть, складывается ощущение, что модель данных появилась только с ORM (поэтому и запутался). Не по теме: Спасибо, что осилили мои много буков :D 0

@Usaga 12078 / 8387 / 1281 Регистрация: 21.01.2016 Сообщений: 31,595
	28.12.2018, 10:54	4
	Сообщение от OttoFix складывается ощущение, что модель данных появилась только с ORM Идеология EF'а - косить под бизнес-модель приложения. И он это делает очень успешно. Что и приводит к путанице. Люди реально воспринимают сущности EF'а как бизнес-модель и что их не отличить. 0

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

@Usaga 12078 / 8387 / 1281 Регистрация: 21.01.2016 Сообщений: 31,595
	29.12.2018, 06:49	6
	Сообщение от OttoFix а репозиторий должен оперировать так сказать "сырыми" данными из базы, а не готовыми выборками из процедур. Да? С чего бы это вдруг? Сообщение от OttoFix Я правильно понимаю, для построения приложения по такому описанию, база должна содержать только сущности и логику целостности данных? База может содержать что угодно. Репозиториям до фонаря. Как я уже ранее говорил, репозитории работают с любыми видами хранилищ данных. 0

@Usaga 12078 / 8387 / 1281 Регистрация: 21.01.2016 Сообщений: 31,595
	29.12.2018, 07:39	8
	Сообщение от OttoFix Если логика в базе SQL (построена на процедурах и функциях), то нам данные из этой таблицы в чистом виде не нужны, но данные из нее присутствуют в результирующих выборках некой процедуры. И как можно создать репозиторий для процедуры, результатом которой является некое объединение трех таблиц? Разве это не будет нарушением? Нарушением чего? Вам приходит выборка (не важно, чистым SQL'ом сформированная или полученная от процедуры). Вы её мапите на класс. Что здесь чему противоречит и что нарушается? Я же русским языком сказал, что источник данных для репозитория роли не играет. А уж что данные формирует - чистый SQL или процедура - подавно плевать. Сообщение от OttoFix Это я понимаю, но база тоже должна быть спроектирована под определенные концепции, я про это. Ну так и проектируйте её так, как вам надо. Репозитории вам тут не помешают ничем. Они лишь выступают адаптерами между хранилищем и бизнес-логикой. 2

@Tessio 79 / 102 / 44 Регистрация: 12.05.2015 Сообщений: 476
	29.12.2018, 07:50	9
	Сообщение от OttoFix Разве это не будет нарушением? Нарушением чего? Репозиторий - это абстракция, пользователям репозитория, совершенно не важно что там происходит в методах, им необходимо либо получить данные, либо их отдать для добавления, изменения или удаления. А для репозитория всё равно как источник данных отдаёт данные, через запросы или процедуры. Сообщение от OttoFix придется отказаться от идеи использовать модель данных А вот это совершенно неверный подход. 0

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331
	29.12.2018, 08:51 [ТС]	10
	Сообщение от Usaga Нарушением чего? Это я уже про разделение слоев база данных - бизнес логика - и.д. (извиняюсь в путанице). Сообщение от Usaga Вы её мапите на класс. В моем случае, это будет лишним телодвижением, так как выборка уже готовый результат, который необходимо только отобразить пользователю. Естественно полного просветления за несколько часов я не получил, но хотя бы начал улавливать суть. На практике думаю понимание придет лучше, поэтому начну понемногу разрабатывать тестовый проект. Как на Ваш взгляд, репозиторий должен быть один или для каждой сущности свой? Просто везде пишут по-разному. Еще раз спасибо за разъяснения. Добавлено через 5 минут Сообщение от Tessio А вот это совершенно неверный подход. Возможно, но очень не хочется переделывать базу. Из программы нет ни одного инсерта, апдейта или селекта, все идет через процедуры, на них есть свои ограничения в правах. Таким образом программа только выполняет роль удобного вьювера и удобного запуска процедур обработки. Добавлено через 19 минут Добавлю, что бы Вы не подумали, что Ваши советы были напрасны. Я естественно продолжу дальше разбираться с этим вопросом, но это требует времени. А проект я не могу "заморозить" на неопределенный срок, поэтому я его доделаю с текущей базой и работой с dataadepter. 0

@Usaga 12078 / 8387 / 1281 Регистрация: 21.01.2016 Сообщений: 31,595
	29.12.2018, 08:57	11
	Сообщение от OttoFix Это я уже про разделение слоев база данных - бизнес логика - и.д. (извиняюсь в путанице). Какие слои ещё? Репозиторию на это наплевать. У него есть интерфейс общения с СУБД, через который он и получает данные. А какие там слои в СУБД - это аспект самой СУБД и за её пределы не выходит. Сообщение от OttoFix В моем случае, это будет лишним телодвижением, так как выборка уже готовый результат, который необходимо только отобразить пользователю. Нет, не лишним. Вы мапите представление данных полученное из хранилища (DataTable, SqlDataAdapter, SqlDataReader) в то, с чем удобно работать бизнес-логике. Ну и обратно. Сообщение от OttoFix Как на Ваш взгляд, репозиторий должен быть один или для каждой сущности свой? Просто везде пишут по-разному. Репозиторий на агрегат. Сообщение от OttoFix Возможно, но очень не хочется переделывать базу. Её не надо переделывать. Переделкой занимается репозиторий. На ходу. 0

@OttoFix 113 / 89 / 26 Регистрация: 11.12.2018 Сообщений: 331
	29.12.2018, 09:02 [ТС]	12
	Сообщение от Usaga с чем удобно работать бизнес-логике В программе её нет, поэтому программе достаточно только SqlDataAdapter, DataTable. 0

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

@Cupko 653 / 589 / 171 Регистрация: 17.07.2012 Сообщений: 1,670 Записей в блоге: 1
	29.12.2018, 12:30	18
	Сообщение от Usaga Это как это так? Я сначала написал "невозможно", но быстро осознал, что если очень хочется... Репозиторий - он все же есть подобие коллекции для доменных объектов. И очень сложно представить коллекцию, когда у тебя есть хранимка возвращающая одну запись, но нет хранимки для нескольких, для поиска, для Edit/Update/Delete. Получается уж очень как-то кривовато. Нет, вы можете назвать свои DAL объекты репозиторием, но от этого они репозиториями не станут. 0

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

@Cupko 653 / 589 / 171 Регистрация: 17.07.2012 Сообщений: 1,670 Записей в блоге: 1
	29.12.2018, 16:07	20
	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 архитектуре. 0

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

Решение