Архитектура S # arp против прямой IOC + NHibernate + MVC

Question

Достаточно ли преимуществ для использования другой внешней сборки? Насколько сложно удалить S # arp и сохранить NHibernate на более позднем этапе?

Answer 1

Луис Абреу имеет большое количество записей в блоге по архитектуре S # arp, в которых обсуждаются наиболее важные сборки в проекте. Они, безусловно, помогли мне понять основы Рамочной.

Answer 2

Я предпочитаю прямой IoC + NHibernate + MVC.

Несколько месяцев назад я взглянул на архитектуру S # arp одновременно с переходом на IoC и Mvc. Я тщательно его выбрал. Мне нравится, как проект управляет сессиями NHibernate очень удобным для тестирования способом. Я перенес этот дизайн в свои собственные проекты. Но я чувствовал, что мне будет лучше понять, что происходит, и просто настроить только то, что мне нужно в моей собственной архитектуре проекта.

IoC не сложно настроить. NHibernate + Fluent NHibernate не сложно настроить, как только вы сделали это пару раз. Я предпочитаю знать мой код, особенно когда он такой простой, как IoC и NHibernate, а не делегировать реализацию в черный ящик.

Answer 3

Я думаю, что будут проблемы с сохранением всего - S # arp не маленький вспомогательный класс только для NHibernate. Интеграция с ним должна быть плотной.

Если бы мне пришлось начать свой проект еще раз - я бы использовал архитектуру S # arp. Этот пример проекта Northwind для меня выглядит как леденец на палочке.

Поэтому - если вы чувствуете себя хорошо с внешними библиотеками - дерзайте!

Answer 4

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