Использование интерфейсов с Linq-to-Sql для разделения

Я реорганизую класс модели в интерфейс. Класс модели автоматически создается с помощью Linq-to-Sql.

class FooRepository 
{
    // ...
    public void Add(IFoo foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

Метод InsertOnSubmit принимает экземпляр Foo, а не IFoo. Я могу встроить экземпляр в (Foo), и это работает, но есть ли более чистый способ сделать это?

Я уже использую StructureMap, могу ли я добавить атрибут к методу Add для разрешения типа на основе моих сопоставлений?

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


c# interface decoupling structuremap
person blu    schedule 29.08.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Чтобы отделить модель DLINQ от контроллера, я стараюсь не передавать модель LINQ, а использую другую модель, используемую контроллером, которая передается в мой класс перед вызовом методов DLINQ.

Таким образом, я могу иметь в своем контроллере только те свойства, которые необходимы приложению, даже если в базе данных может быть много других свойств.

Таким образом, при изменении структуры базы данных должен измениться только класс DAO, такой как FooRepository, а все остальное защищено от волнового эффекта.

Я не знаю, захотите ли вы сделать что-то подобное, но я ожидаю, что это будет более простой дизайн, чем использование интерфейсов.

person James Black    schedule 29.08.2009
comment
Мои контроллеры используют интерфейсы для модели и переводят их в объекты ViewModel. Я слышал, что вы говорите о том, что не используете модель LINQ, кроме как в области доступа к данным/репозиторию, и сопоставляете их с разными классами. Использование интерфейсов действительно дало мне большую гибкость для управления изменениями в одной области, чтобы они не влияли на другие. - person blu; 29.08.2009
comment
+1, потому что это неплохой ответ, просто это не то, что я ищу прямо сейчас. - person blu; 29.08.2009
comment
Просто кажется, что использование интерфейсов для чего-то, что в идеале является просто классом свойств, может быть излишним, поскольку вы будете определять свойства в интерфейсе, а затем в классе. Я склонен использовать class User { public String Name { get; набор; } } Так что мой класс для интерфейса будет идентичен интерфейсу. - person James Black; 29.08.2009
comment
Я ценю ваш вклад, но все еще ищу ответ на исходный вопрос. - person blu; 01.09.2009
comment
В итоге я перешел к этому подходу в целом, спасибо за вклад. - person blu; 29.01.2010

arrow_upward
0
arrow_downward

Не знаю, подойдет ли это, но, возможно, идея использовать genrics?

class FooRepository<T>
where T: class, IFoo, new() 
{
    // ...
    public void Add(T foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

И вы можете сделать что-то вроде этого -

Foo bar = new Foo();
FooRepository<Foo> foo = new FooRepository<Foo>();
bar.Add(bar);

Или это...

Bar bar = new Bar(); //Bar implements IFoo
FooRepository<Bar> foo = new FooRepository<Bar>();
bar.Add(bar);

Таким образом, T в FooRepository на самом деле является Foo (или Bar), а не IFoo, поэтому приведение не требуется, но ограничение в предложении where означает, что он должен реализовывать IFoo, что и Foo (и Bar).

person Frank Tzanabetis    schedule 28.01.2010