Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, another_coder, Вы писали:

_>>Думаю, что предполагать о заменяемости типа хранилища сейчас моветон. А вот об изолированности от него во время тестов — это то, что нужно. Совсем отрицать, что "ORM должны лежать в отдельной сборке с атрибутом internal." так же глупо, как и думать, что все абсолютно можно спрятать за ширмой абстракции. Но важно подразумевать, что в один момент кто-то захочет переписать и выкинуть ваш кусок кода и это должно быть легко и просто.
S>Ок, давайте разбираться. У нас есть совершенно разные требования, типа
S>- возможность заменить природу хранилища (не нужно)
S>- тестируемость (требует исследования, т.к. для разных видов тестов нужно изолировать разные компоненты)
S>- возможность локализовать изменения кода при изменении требований (у нас должно быть представление о том, какого рода ожидаются изменения)
S>По факту получается, что самое важное требование — последнее. И разные архитектуры по-разному его поддерживают. В частности, всякие table gateway, репозитории, и хранимки вида sp_AddProduct, sp_GetProduct, sp_DeleteProduct, sp_UpdateProduct — это просто мусор, который осложняет процесс разработки, не давая никаких преимуществ.

Мне не понятны требования. Они слишком общие. Хотя бы надо или нет заменить хранилище? Полагаю, что если вы будете придерживаться SOLID при дальнейшем проектировании и рефакторинге, то проблемы постепенно уменьшутся. Т.к. вы получите изолированности, и как следствие, возможность заменить хранилище и тестировать.
Опять же, стоит четко понимать зачем тесты и какие в каждом случае необходимы.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, another_coder, Вы писали:

_>>Думаю, что предполагать о заменяемости типа хранилища сейчас моветон. А вот об изолированности от него во время тестов — это то, что нужно. Совсем отрицать, что "ORM должны лежать в отдельной сборке с атрибутом internal." так же глупо, как и думать, что все абсолютно можно спрятать за ширмой абстракции. Но важно подразумевать, что в один момент кто-то захочет переписать и выкинуть ваш кусок кода и это должно быть легко и просто.
S>Ок, давайте разбираться. У нас есть совершенно разные требования, типа
S>- возможность заменить природу хранилища (не нужно)
S>- тестируемость (требует исследования, т.к. для разных видов тестов нужно изолировать разные компоненты)
S>- возможность локализовать изменения кода при изменении требований (у нас должно быть представление о том, какого рода ожидаются изменения)
S>По факту получается, что самое важное требование — последнее. И разные архитектуры по-разному его поддерживают. В частности, всякие table gateway, репозитории, и хранимки вида sp_AddProduct, sp_GetProduct, sp_DeleteProduct, sp_UpdateProduct — это просто мусор, который осложняет процесс разработки, не давая никаких преимуществ.

Мне не понятны требования. Они слишком общие. Хотя бы надо или нет заменить хранилище? Полагаю, что если вы будете придерживаться SOLID при дальнейшем проектировании и рефакторинге, то проблемы постепенно уменьшатся. Т.к. вы получите изолированности, и как следствие, возможность заменить хранилище и тестировать.
Опять же, стоит четко понимать зачем тесты и какие в каждом случае необходимы.