Можно ли сохранить класс, полученный из объекта Linq to SQL?

Скажем, что «Foo» - это объект Linq to SQL, созданный в конструкторе Linq to SQL.Можно ли сохранить класс, полученный из объекта Linq to SQL?

У меня тогда есть «Бар», который происходит от «Foo».

Должен ли я сэкономить «бар» с использованием Linq to SQL (при условии, что мне не нужно сохранять какие-либо дополнительные свойства на панели).

 using (myDataContext ctx = new myDataContext()) 
     { 
      ctx.Foos.InsertOnSubmit(instanceOfBar); 
      ctx.SubmitChanges(); 
     }

Подлежит ли это поддержанию?

Спасибо большое, Jon

источник

2010-08-11 Jon Kragh

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

источник

2010-08-11 01:33:56

Насколько я знаю, это единственный способ сделать это в стороне от переопределения источника сопоставления. По умолчанию реализация атрибута Linq to Sql AttributeMapping извлекает только различные атрибуты (TableAttribute, ColumnAttribute и т. Д.) На базовый тип, игнорирует все, что унаследовано. – rossisdead

Это смешно, после того, как я разместил это, я просто понял, что он не поддерживается, и загрузил automapper http://automapper.codeplex.com/, чтобы сопоставить мой производный объект с новым экземпляром базового класса. (похоже на то, что вы нашли) Отлично работает. Я также расширил базовый класс событием, которое запускается до сохранения, чтобы производный класс сериализовал свои данные расширения в xml (который сохраняется в столбце xml в схеме базовых классов). –

Я не уверен, но почему вы это делаете? Все объекты реализованы как частичные классы, так почему бы вам просто не реализовать то, что вы хотите в частичном классе?

источник

2010-08-11 01:02:44 Shlomo

Причина заключается в том, что я хочу Linq в код SQL, чтобы быть в библиотеке/DLL что я могу повторно использовать во многих приложениях и в приложениях, которые используют эту библиотеку, я хотел бы расширить сущности с конкретными знаниями приложений. –

Я бы использовал шаблон репозитория: Не подвергайте Linq To SQL Data Context, отмечайте его как внутреннее. У вас есть тонкая обертка над ним (хранилище), а затем выложите это. Методы репозитория могут преобразовывать расширенные классы в базовые объекты datacontext. – Shlomo

Я сторонник шаблона репозитория, что означает, что я определяю свои модели в изолированной dll (project.Models.dll), а затем создаю реализацию LinqToSql моего IRepository.

Классы linq существуют только в DLL-реализации LinqToSql, и я создаю методы расширения для преобразования из моих моделей в объекты linq и наоборот.

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

Что тогда означает, что у вас есть полный контроль над сериализации ваших объектов, и может делать почти все, что вы хотите с ними

источник

2010-08-11 01:52:43 Dylan

Можно ли сохранить класс, полученный из объекта Linq to SQL?

ответ

Смежные вопросы