@AnyaZaychnko

Дорогие форумчане, прошу у вас помощи
Пишу сейчас небольшое клиент-серверное приложение на C#
На сервере установлен MS SQL Server и для доступа к данным использую Entity Framework.
Собственно я столкнулась с одной проблемой и надеюсь на помощь)
Я использую метод DataBase first и Entity Framework создает мне классы на основе моей БД.
Можно ли вынести все эти классы в отдельную dll, чтобы можно было использовать их одновременно на сервере и клиенте?
Эту же базу данных я планирую использовать еще и в ASP.NET приложении. Поэтому не хотелось бы создавать 3 одинаковые версии одних и тех же сущностей.
Будет ли это хорошей идеей и есть ли вообще другие варианты?
Спасибо за помощь

0

@Usaga

Не просто можно, а нужно так делать. Причём очень желательно сами классы сущностей держать в одной сборке, а класс контекста и мапинга в другой. Так можно будет весь уровень работы с данными переиспользовать (если надо).

Просто создайте в солюшене ещё проекты (один под классы сущностей, другой под контекст) и перетащите классы по проектам. Простанства имён подправьте ещё, что бы отражали расположение классов.

Учтите, что клиенту данные могут понадобиться не в том виде, в каком они храняться в базе и представлены в модели данных Entity Framework. Разница может быть как в типе полей, их количестве и содержимом. К примеру, у вас может быть таблица пользователей, где хранятся отдельно поля под ФИО и поле даты рождения, но клиенту, в каком-то сценарии, может понадобиться ФИО слитое в одну строку через пробелы и возраст числом (не дата рождения). Оригинальный класс таблицы пользователей уже не подойдёт.

Поэтому настоятельно рекомендуется завести ещё один проект, чисто под классы, для обмена данными между клиентом и сервером.

1

@AnyaZaychnko

Спасибо за ответ.
Но у меня теперь появились немного другие вопросы.
Если я создам отдельную dll с сущностями, которые точно будут и на стороне сервера и на стороне клиента( будут иметь одинаковый вид, набор полей и методов). А уже потом наследоваться от этих классов и расширять их функционал отдельно для сервера и отдельно для клиента? Я мыслю в правильном направлении или сильно заблуждаюсь?
Если я так сделаю, то как мне это объединить с Entity Framework и не будет ли потерян смысл использования этого фреймворка?
Спасибо)

0

@Usaga

Не надо так делать. У класса всегда должно быть одно назначение, один сценарий использования. Я же в посте выше чётко описал, что делать в такой ситуации: заводить отдельный класс, который данные будет хранить в более подходящем для сценария использования формате. Не надо городить иерархии наследования, это всё захламит.

Если класс из модели EF не будет подходить для каких-то сценариев, то смело заводите более удобный класс. Данные между такими классами можно смело переносить (или руками или через Automapper). И сам EF умеет считывать данные в классы не входящие в его модель. Т.е. если в каком-то сценарии вам понадобится только пара полей из таблицы, то не обязательно считывать вообще всё, чтобы взять подмножество, можно считать только нужное в более подходящий меньший класс через Select().

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

1

@AnyaZaychnko

Спасибо большое за ответ)

0