Сопоставление интерфейса не поддерживается, но объект Linq-Sql уже реализует свойство

Итак, я создал DataContext (Linq-Sql) в VS из существующей базы данных. У него есть таблица с именем «Пользователи», поэтому у меня есть объект User. В частности, я хочу сосредоточиться на свойствах UserID и Username.

Теперь у меня есть интерфейс:

interface IUser
{
     int Id { get; }
     string Username { get; }
}

Я хочу создать частичный класс User и реализовать IUser. Причина этого в том, что я могу рассматривать любого пользователя как IUser во многих местах и ​​не беспокоиться о точном классе User:

public partial class User : IUser
{
    public int Id
    {
         get { return UserID; }
    }
}

Я не реализую свойство Username get, потому что знаю, что объект сущности уже реализует его.

Когда у меня есть такой запрос, как dc.Users.SingleOrDefault(p => p.Id == 5);, я знаю, что это ошибка, потому что он преобразует этот вызов в оператор SQL и попытается найти столбец Id, которого не существует — UserID существует. Так что я понимаю эту проблему отображения.

Когда я запрашиваю dc.Users.SingleOrDefault(p => p.Username == "admin"), он также выдает ошибку, НО Username действительно существующий столбец в базе данных, поэтому у меня сложилось впечатление, что никакого пользовательского/дополнительного сопоставления не требуется. Что мне не хватает?

Может ли кто-нибудь указать мне на хороший источник о том, как бороться с Linq и частичными классами, реализующими пользовательский интерфейс?

Вопрос об обновлении: прежде чем я попробую, кто-нибудь знает, будет ли "оснащение" файла datacontext.designer.cs нашими пользовательскими интерфейсами (для реализации в самих классах, а не в отдельном файле частичного класса) Работа? Есть ли последствие этого?


person Mickael Caruso    schedule 04.01.2013    source источник
comment
Какую ошибку вы получаете для dc.Users.SingleOrDefault(p => p.Username == "admin") Это должно работать, предполагая, что имя пользователя является свойством с нормальным отображением.   -  person usr    schedule 05.01.2013
comment
Я знаю. Не должно, но только потому, что имя пользователя является членом интерфейса, он жалуется: сопоставление члена интерфейса IUser.Username не поддерживается.   -  person Mickael Caruso    schedule 05.01.2013
comment
Теперь я понимаю. Какой статический тип p в этой лямбде? Каков статический тип dc.Users?   -  person usr    schedule 05.01.2013
comment
dc.Users Я думаю, что это System.Data.Linq.Table‹User›. и p будет пользователем, общим типом параметра таблицы. Хотя не знаю, как это поможет.   -  person Mickael Caruso    schedule 05.01.2013
comment
Поскольку LINQ жалуется, что вы использовали IUser.Username. Почему оно так думает? Похоже, это ошибка: gonale.com/2009/07/22/ (Но вы понимаете, что не можете ожидать, что LINQ будет понимать элементы интерфейса, верно? Они не отображаются.)   -  person usr    schedule 05.01.2013


Ответы (1)


Я столкнулся с этим до использования Generics и LINQ, и я решил это, заменив p.Id == 5 на p.Id.Equals(5), и LINQ смог сопоставить запрос.

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

Какой лучший способ динамической реализации интерфейс на C#?

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

К сожалению, у меня недостаточно опыта работы с LINQ или .NET, чтобы объяснить, почему Equals() работает, а == нет :)

person Ryan Allen    schedule 22.04.2015