Repository или CQRS?

Question

[stud3nt]

Здравствуйте!
Я разрабатываю один проект (ASP.NET MVC) и у меня возник вопрос, касающийся архитектуры приложения. В интернете я нашел много материала по данному вопросу, но все же некоторые вопросы у меня остались. Больше всего мне понравилась идея CQRS, но для меня осталось непонятным то, как лучше это реализовать в проекте (хотелось бы без репозиториев и eventsourcing). Проектировщик из меня фиговый и поэтому я решил задать вопрос здесь. + хотелось бы узнать какие шаблоны проектирования посоветуете вы.

Answer 1

[Тимур Шемсединов]

Вот так всегда, очаровались красивой идеей, где-то что-то понравилось, руки чешутся применить... А нужно оно или не нужно... Отталкивайтесь от того, что хотите сделать, а Вы об этом так и не рассказали, и уже потом можно переходить к тому, какую парадигму выбрать, потом выбирать паттерны, фреймворки, библиотеки (но лучше как можно меньше их конечно). Вот для чего Вам CQRS? Что он будет решать и почему без него не лучше? Вы не сможете ответить на эти вопросы если не будете идти от задачи. А потом так и выходит: "что не напишу - все контроллер выходит, это наверно потому, что я все время думаю о контроллерах" )))

Answer 2

[Валерий Абакумов]

Добрый день!

Честно говоря, не знаю, что именно Вам понравилось в CQRS и EventSourcing. На мой взгляд, это слишком сложный, непривычный подход, который может использоваться в исключительно редких случаях (как сказал Тимур Шемсединов, все зависит от задачи). Подходы к проектированию приложения нужно применять не тогда, когда они нравятся, а тогда, когда нужно решить конкретную проблему. Если при разработке приложений всегда делать "всякие такие интересные штуки", то процесс разработки уйдет в бесконечность... Проектируйте по принципу: есть задача - как лучше (под "лучше" я понимаю: просто, эффективно, быстро) ее решить. Всё. Если проект "исключительно" в целях обучения - то пожалуйста, здесь Вы вольны использовать всё, что душе угодно. Но если проект реальный, и он Вас "кормит", то тут следует сдерживать свое рвение к новым подходам и всегда задавать вопрос: эта технология/паттерн/механизм/подход поможет решить мне эту задачу? Да - значит, берем, учим, используем, внедряем. Нет - значит, нафиг. Потом больше геморроя будет с сопровождением и изменением кода (и думайте всегда о том разработчике, которому достанется Ваш код после Вас).