#c# #entity-framework #s#arp-architecture
#c# #entity-framework #s #arp-архитектура
Вопрос:
Допустим, у меня есть таблица ‘Customer’ в базе данных SQL, и я использую Entity Framework.
Теперь, например, в Controller или ViewModel я извлекаю клиента по var customer = Page.Current.Customer
, когда его код находится:
public class Page
{
...
// Customer is EntityObject that created by Entity Framework
public Customer Customer
{
get
{
return (new ContextEntity()).Customers.First();
}
}
}
Мой вопрос:
Должен ли я ссылаться на класс объектов Entity (Customer) как DAL и создать CustomerWrapper или я могу использовать его в другом коде моего приложения?
Я имею в виду, правильно ли это, что Page.Current.Customer
вернет объект Customer, или я должен использовать объект Customer как DAL и страницу.Текущий.Клиент должен возвращать пользовательский Customer, какой-то CustomWrapper?
С одной стороны, если уилл решит изменить имя таблицы Customer на site_Customer (в SQL DB), я обновлю EntityModel и изменю код в классе Page только на
public class Page
{
...
// Customer is EntityObject that created by Entity Framework
public Customer Customer
{
get
{
return (new ContextEntity()).site_Customers.First();
}
}
}
Но, с другой стороны, у меня будет объект Customer WrapperCustomer
Что лучше?
Комментарии:
1. Почему вы пометили это [s # arp-architecture]?
Ответ №1:
Все классы в файле EDMX являются частичными классами. Это означает, что вы можете расширить эти классы, создав новый файл класса.
Например…
public partial class Customer
{
// Here are the methods, properties, relationships created by EDMX Wizard.
}
В другой области вашего проекта, я обычно размещаю его в том же месте, что и EDMX, вы можете добавить новый файл класса, который имеет ту же подпись.
public partial class Customer
{
// Here are the methods, properties, etc. created by you.
}
Когда проект будет скомпилирован, эти два класса станут одним классом в скомпилированном коде. Теперь, когда вы меняете свой EDMX, да, он должен отображаться правильно, но это не всегда так, поскольку EF, как известно, очень глючит (предполагается, что это исправлено с помощью EF 4.1 в MVC 3), вы можете просто изменить имя класса, чтобы оно соответствовало тому, что есть в EDMX, и «Вуаля!» вы перенесли весь пользовательский добавленный код для класса в новый объект entity. По сути, это ваша «оболочка класса».
Ответ №2:
Все зависит от уровня абстракции, который вы хотите использовать в своем приложении, и потребностей уровня представления. Возможны оба подхода.
Ваш код, вероятно, уже тесно связан с Entity Framework ( EntityObject
имеет тип EF), а также не очень хорошо поддается тестированию ( Page.Current
вероятно, статичен), поэтому обсуждение некоторых более продвинутых архитектурных подходов и разделения проблем не требуется.
Несколько замечаний из вашего кода:
- Контекст одноразовый!!!
- Переименование чего-либо в вашей базе данных не должно изменять имена ваших классов. В обязанности EF mapping (EDMX) входит корректное сопоставление объектов с новыми именами базы данных.
Комментарии:
1. если вы имеете в виду использование IoC, то я сменил контроллер, и он принимает IProject в своем .ctor. Что касается 2-го пункта: но если бы я использовал во всем своем приложении (контроллер, ViewModels, другие классы) класс site_Customer , а завтра имя таблицы изменилось на t_Customer , поэтому мне нужно будет изменить весь site_Customer на t_Customer . Но если бы я использовал какой-то CustomerWrapper во всем своем приложении, единственным изменением было бы
...t_Customers.First<CustomerWrapper>();
2. Изменение имени таблицы не влияет только на отображение вашего приложения. Ваши классы и наборы объектов не обязательно должны использовать то же имя, что и таблицы. Вы можете настроить имена в конструкторе объектов.
3. Итак, я могу изменить имена таблиц, а затем вручную сопоставить их, верно?
4. ДА. Как только вы обновите модель из базы данных, объект все еще будет в вашей модели, но вы должны открыть сведения о его сопоставлении и сопоставить его с новой таблицей и ее столбцами.
Ответ №3:
Если вы хотите использовать WCF, то вам, вероятно, потребуется создать четкие POCOs, чтобы избежать множества проблем.
Если вы хотите, чтобы ваши контроллеры / viewmodels / страницы / что угодно было доступно для модульного тестирования, тогда вам нужно будет абстрагировать ваш EntityContext в интерфейсах репозитория классы (см. Шаблон репозитория).
Если вы просто хотите создать быстрое и простое приложение, не поддающееся тестированию, то вам не нужно беспокоиться об этом. Не забывайте удалять контекст данных в конце каждого запроса.