Какой наиболее правильный паттерн при работе с SQLite

Что есть:
Entity Framework - набор классов для работы с базой данных
WPF - забинденные Listview ... DataGrid ... Combobox к свойствам контекста (ObservableCollection)
Много форм, где контекст изменяется

Что надо:
подсказать наиболее рациональный паттерн. Изменяя контекст - изменялись бы (обновлялись) все контролы на всех формах автоматом (может по событиям?) Т.е. в одной форме происходит отображение одной главной таблицы, во второй форме создаётся новый объект.

Добавлено через 1 минуту
На данный момент реализовал всё через костыльные события и, что ещё хуже для обновления контролов обнуляю ссылку на коллекцию которая была привязана, потом подключаю её ещё раз - так обновляется.

0

Попробуйте, предварительно перечитав доки. Начинайте с простого.

0

Оно то да. Только вот посоветовали отделить Entity. Создать репозиторий, для того чтобы не воздействовать на контекст и на базу напрямую. Потом создать уже отдельную модель, а потом уже mvvm.

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

Сообщение от jcp Начинайте с простого.

Не хочется "простого". Хочется правильного.

0

skilllab, Что значит правильно?) Для каждой задачи существуют свои методы их решения. А если ты хочешь попрактиковаться, то сделай обычную 3х уровневую архитекту своего приложения (UI слой, слой доменной модели, слой БД). Естественно, репозиторий, для предоставления абстракции для хранения сущностей (а не для воздействия на БД. Репозиторий, не более, чем просто коллекция. Просто абстракция, где хранятся данные, дабы не привязываться к конкретной реализации). В доменном слое у тебя доменные модели (POCO-классы обычные), какие то сервисы, которые поставляют тебе объекты в слой приложения. Естественно, все эти сервисы используются через DI, дабы уменьшить связанность твоего приложения и программировать на уровне интерфейсов, а не конкретных реализаций. Ну и можно DTO реализовать, если ты клиент-серверное что то пилить собрался.

P.S. А еще я тебе советую это (прям сам реализуй по примерам, а не слизывай с исходников, пытайся вникнуть и всё такое): http://www.codeproject.com/Art... n-Practice
Может мало поймёшь, зато английский будет повод подтянуть)

1

Сообщение от Topotun для предоставления абстракции для хранения сущностей

Есть у меня и свои абстракции, которые расширяют функционал сущностей. Только вот вопрос:
ты пишешь, что репозиторий для хранения. Я сам понимаю, что нужно нечто, что будет внутри себя обрабатывать данные, и уже после обновлять их в базе.
Сам Repository:
не вижу тут представления базы данных, лишь методы реализующие взаимодействие. Это я к чему, если я что-то там изменил в, к примеру, Students, то через этот вышеописанный Repository я просто сначала! получаю из базы самих Students, а потом ещё на них же Update делаю. Где тут абстрактное хранилище сущностей? В каждой кнопке на форме я, судя по коду выше, тупо долблюсь в базу почти (через свои представления сущностей а потом и через сами сущности) напрямую.
------------------------

Сообщение от Topotun Что значит правильно?)

это я и выясняю.

Сообщение от Topotun клиент-серверное что то пилить собрался

неа, просто своя базка для хранения. Локальная. В файле. Так захотел. На этом и останусь.

Сообщение от Topotun Может мало поймёшь

если не буду понимать, то на форум то и обращусь на то его и придумали.

Решения с "упростить в связи с тем что делаешь всё локально и для себя" не предлагать. Я уже "так" сделал, теперь хочу познать науку.

Добавлено через 9 минут
Добавлено: хотяя...хранение представления базы данных в коде, может занять пипец какой объём оперативки. Так что может подход и верный.

0

skilllab,

Где тут абстрактное хранилище сущностей?

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

0

Сообщение от Topotun для предоставления абстракции для хранения сущностей

Может тут игра слов? ))) Хранение сущностей это что? И где конкретно происходит хранение?
ибо

Сообщение от Topotun Репозиторий, у тебя абстракция, между

Добавлено через 52 минуты
Может я радикально что-то не понимаю. Накатаю вечером проект, выложу.Topotun,
сможете просто подсказать, помочь, в правильном ли я направлении всё делаю?

0

EF вполне себе репозиторий сам по себе. Он собственно для того и был создан, чтобы не писать репозиторий-бойлерплейт, а просто сказать "сделай мне репозиторий для такой-то базы".

0

Psilon, Создан он был для этого, но видимо не сложилось. И всегда (ну, часто очень) создают абстракцию поверх абстракции из-за проблем совместимости разных провайдеров данных. Сценарий, который ты выполняешь, используя один провайдер, может некорректно работать на другом. И типы данных (не все типы данных из EF поддерживаются базами данных). Производительность (само собой). А еще проблема в IQueryable, который предоставляет универсальный интефейс, который позволяет писать огромное количество разнообразных запросов. Всё бы хорошо, но не все разработчики конкретных LINQ провайдеров их поддерживают, поэтому, создав абстракцию (репозиторий) поверх EF, можно создать репозиторий со своим интерфейсом, с помощью которого можно будет как то органичить запросы

skilllab,
Добавлено через 22 минуты

Может я радикально что-то не понимаю.

Тут собака зарыта в том, что на разных языках говорим. Что такое сущности? Зачем вообще нужен репозиторий? Для взаимодействия и/или для хранения? А может есть еще какие то цели, зачем люди пользуются данным паттерном? Так репозиторий ("истинный") всё таки хранит что то или не хранит? А может у тебя не репозиторий реализован, а просто набор функций для взаимодействий с БД? А почему бы эти функции просто в статический класс не захерачить, чтоб геморроя меньше не было? А может лучше воспользоваться другим паттерном, для реализации того, что сейчас у тебя реализовано? Зачем ты вообще абстракцию какую то создаёшь? Уверен ли ты, что ты реализовываешь именно репозиторий?

Ответь сначала (для себя, а не мне) на эти вопросы сам (без гугла). А потом, когда поймёшь, что у тебя очень много пробелов, тогда открывай гугл и читай, очень много читай.
Я не вижу смысла отвечать на такие вещи, когда даже в базовых вещах трудности, потому что так можно днями напролёт переписываться и на пустом месте спорить.

P.S. Конкретный смысл репозитория - скрывать способ доступа к данным от остальных слоёв ПО. Репозиторий, это всё такие хранилище. Хранит репозиторий Entity (сущности). В идеале, поверх репозитория пишут сервисный слой, который Entity преобразовывает (принимают и отдают) в DTO объекты и эти объекты уже передаёт уже другим слоям ПО. Так, что бы Entity не была видна за пределами этих сервисов.

1

Topotun,
1) EF поддерживает многопровайдерность
2) Всегда можно накрутить слой абстракции поверх, с которым будет удобнее работать. Главное, чтобы этих слоев не стало слишком много.

0

Psilon, Я разве написал, что EF не поддерживает многопровайдерность?) Поддерживает. Только проблема то в другом. Проблема в том, что на практике, разные провайдеры могут вести себя (и не только могут, но и ведут) по разному.
Тут вопрос не удобства, а необходимости

0

Topotun, так-то да. Я ж говорю, всегда можно накрутить слой абстракции поверх, и почти вседа он будет удобнее нижележащего. На этом вообще все программирование построено. Вопрос только в пользе от такого слоя. Ибо она бывает меньше, чем удобство от неё. Я помню пробовал в свое время прикрутить свой слой работы с AD поверх стандартного. В результате после кучи рефакторинга практически все выкинулось. Осталась только пара методов расширений, вроде транзакционного изменения нескольких свойство в сущности с rollback'ом в случае неудачи. Короче, пользы от этого слоя было мало, и я от него избавился. Просто такой вот пример из личного опыта.

0

Psilon, Спасибо за пример из личного опыта (реально спасибо, без сарказма). А по поводу всего остального, меня просто смутило, что ты постоянно говоришь про "удобство". У меня просто "удобство" ассоциируется просто с плюшками, которые не особо то и нужны. Но абстракция, поверх абстракции иногда бывает жизненно необходимо) А ты говоришь про "удобство". Может, конечно, это лично мои загоны, но когда ты работаешь в команде из 5ти разработчиков, то про удобство говорить слишком эгоистично, так как то, что тебе удобно, может быть другим ребятам не удобно=)
Ну а суть я уловил. Разными словами об одном и том же говорили

0

Сообщение от Psilon Вопрос только в пользе от такого слоя.

Да те же самые проверки на ввод, к примеру строка должна быть как IP адрес.

Сообщение от Topotun А может у тебя не репозиторий реализован, а просто набор функций для взаимодействий с БД?

Весь гугл пестрит стандартной мделью

Сообщение от skilllab IEnumerable<Student> GetStudents(); * * * * Student GetStudentByID(int studentId); * * * * void InsertStudent(Student student); * * * * void DeleteStudent(int studentID); * * * * void UpdateStudent(Student student); * * * * void Save();

Что же такое тогда этот репозиторий?

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

Сообщение от Topotun Что такое сущности?

Именно то, что закладывали разработчики.

Сообщение от Topotun Репозиторий, это всё такие хранилище. Хранит репозиторий Entity (сущности).

Сообщение от Topotun Конкретный смысл репозитория - скрывать способ доступа

Так хранить или скрывать? В GetStudents лишь получаем таблицы и дальше их передаём. Где конкретно в репозитории хранятся сущности?

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

Сообщение от Topotun В идеале, поверх репозитория пишут сервисный слой, который Entity преобразовывает

Сообщение от skilllab Есть у меня и свои абстракции, которые расширяют функционал сущностей.

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

0

skilllab, Вопросы были для того, чтоб ты сам себе ответил на них) Я то ответы знаю)

Так хранить или скрывать?

Почему такая категоричность?) Репозиторий - это обычная коллекция + плюшки. А что коллекция делает? Не хранит? А где коллекция данные хранит? Где конкретно хранит данные коллекция?)

Я тебе еще раз повторяю, что то, что ты прислал, это не реализация, а всего лишь интерфейсная часть. Попробуй реализовать

IEnumerable<Student> GetStudents(); * * * * Student GetStudentByID(int studentId); * * * * void InsertStudent(Student student); * * * * void DeleteStudent(int studentID); * * * * void UpdateStudent(Student student); * * * * void Save();

Вот этот код, пока он у тебя заключён в интерфейсе, он ничего абсолютно не значит. Это не паттерн репозиторий, а просто интерфейс твоего будущего (!!!) репозитория. Сейчас этот код не делает ничего абсолютно. Когда начнёт что то делать, тогда будет предмет разговора) А сейчас ты присылаешь код твоего интерфейса и спрашиваешь "правильно ли я репозиторий реализовал?". Отвечу - нет. Не правильно. Ты вообще его не реализовал, а просто объявил интерфейс своего репозитория, который ты когда нибудь реализуешь.

P.S. Ответ может каким то грубым показаться, но ты же понимаешь, что обидеть я тебя не хотел ничем, да?) Вот и хорошо) Мне просто хочется, чтоб ты лично сам (с минимальной поддержкой) победил эту задачу и сам совершил для себя открытие)

0

Кто-то из присутствующих когда-нибудь использовал репозиторий?
По мне это крайне неоднозначная тема

тянуть 1000000 записей из базы чтоб сделать Take(10) явно не вариант вообще
накой пень тогда репозиторий если кишки торчат наружу

это куча лишнего кода и времени, да и вообще бред, в итоге всё сведется к передаче фильтров или Expression что опять же приводит к вопросу накой нужен репозиторий

0

Сообщение от m0nax По мне это крайне неоднозначная тема

Оставить Entity и просто обернуть их набором методов? Так сказать создать Model для всего остального приложения.

0

И кстати если делать - потом по всей программе гонять кучу этих репозиторев?

0

m0nax,

Кто-то из присутствующих когда-нибудь использовал репозиторий?

Кто-то, видимо, использовал.

тянуть 1000000 записей из базы чтоб сделать Take(10) явно не вариант вообще

Вопрос реализации.

накой пень тогда репозиторий если кишки торчат наружу

"наружу" - это куда? Куда у тебя торчат "кишки"? И что за кишки? Как спроектируешь, так и будет "торчать")

это куча лишнего кода и времени, да и вообще бред, в итоге всё сведется к передаче фильтров или Expression что опять же приводит к вопросу накой нужен репозиторий

Так а реально, на кой нужен репозиторий?) Может ты ожидаешь от него бОльшее, чем он есть? У репозитория очень узкая специализация, чем он и хорош. Так основная проблема в том, чтоб тебе фильтрики передавать не пришлось? но...но причём тут репозиторий, если всё дело в фильтрах

Добавлено через 53 секунды
m0nax, Если ты гоняешь по всей программе репозиторий, то это уже проблема в архитектуре всё таки) Я вот тоже не знаю, зачем нужен такой репозиторий, если потом по всей программе его гонять) Скорее в проектировании приложения проблема, а ты паттерн обижаешь)

0

Сообщение от Topotun "наружу" - это куда? Куда у тебя торчат "кишки"? И что за кишки? Как спроектируешь, так и будет "торчать")

ну по идее репозиторий должен кого-то от чего-то абстрагировать, но какая же это абстракция если наружу торчит полный доступ к механизму запросов?
repo.GetStudents().Where(....).Take(..). Order(By..

0