0

Я разрабатываю программное обеспечение (библиотеки, веб-страницы, веб-API, настольные приложения и т. Д.), Используя сначала C#, .NET Framework 4.0 и Entity Framework Code.Есть ли что-то, что нужно сделать для инъекций Dependency с классами моделей?

Чтобы разработать это программное обеспечение, я использую Injection Dependency с Ninject и шаблоны Generic Repository и Unit of Work.

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

Теперь я улучшил свою базу данных, и я изменил модель. База данных имеет ту же функциональность, что и предыдущая, но с меньшим количеством таблиц и меньше столбцов. Для этого я поменял классы POCO E.F., и здесь все мои проблемы. Эти проблемы возникают из-за того, что я использую эти классы POCO внутри своей бизнес-логики, и если я их изменю, мне приходится менять бизнес-логику.

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

Это всегда происходит, или я сделал что-то не так?

+0

_ "... и здесь все мои проблемы" _ - С какими проблемами вы сталкиваетесь? Можете ли вы привести конкретные примеры? –

+0

Эти проблемы возникают из-за того, что я использую эти классы POCO внутри своей бизнес-логики, и если я их изменю, мне придется изменить бизнес-логику. – VansFannel

ответ

0

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

Если вы выделите классы моделей вне рамки сущности и используйте их, вы получите лучшее разделение, но больше типов.

+0

Я согласен с вами до определенной степени. Этот момент является наиболее распространенной ошибкой при использовании EF. Точка EF - это сопоставление объектов домена с вашей базой данных. Entity Framework должна стать точкой гибкости для присоединения к негибкой базе данных с идеализированной моделью домена. Ergo, переработка EF - это именно то, что необходимо для изоляции изменений объектов домена из базы данных. – Aron

+0

Если вы используете EF для определения своих классов моделей, у вас все еще есть изменения определений, когда вы переделываете. Но проблема вокруг Инъекции? Хотя вы можете использовать эти объекты в своих контрактах с интерфейсом, вы никогда не избежите повторной работы, если определения объектов изменятся. Вы могли бы, возможно, связать классы моделей с базовыми функциональными возможностями, но уровень гибкости, который вы хотите, любое решение будет просто перемещать это бремя. Мне было бы интересно узнать, что говорят другие, извините, я не могу придумать другого решения. – kidshaw

+0

Если вы используете EF для определения классов моделей, вы не используете POCOs. – Aron