David_Wimbley
Учитывая, что я начал проект MVC с нуля и в то время был новее, я объясню некоторые свои мысли. Некоторые из них могут быть очевидны, но ваш вопрос не очень ясен с точки зрения того, что именно вы хотите.
Это мое мнение, основанное на моем опыте. Это не значит, что это правильно или на 100% то, что вы должны делать. Просто некоторые вещи я могу сделать по-другому, если мне представится такая возможность.
1) Абстрагируйте свой код от контроллера. Это позволит использовать его повторно. Это означает, что у вас есть операция калькулятора и логика встроена непосредственно в ваш контроллер. Вытащите это в класс калькулятора.
Вы никогда не узнаете, когда вам может понадобиться использовать это в другом месте, и не хотите быть в непрерывном цикле рефакторинга.
2) Посмотрите на веб-API. Возможно, сегодня вы создаете только приложение MVC, но если вам нужно создать разбавленный портал или мобильное приложение, вы можете иметь средний уровень в web api без необходимости иметь один и тот же код повсюду.
Ваше приложение MVC будет интегрироваться со слоем web api.
3) Не экономьте на модульном тестировании. В групповой среде, если вы пишете какой-то код без документации или модульных тестов, вероятно, планируете потратить много времени на объяснение того, как работает ваш код, пока Вы, наконец, не задокументируете его или не напишете модульные тесты.
На мой взгляд, модульные тесты-это не просто тесты, это хороший способ показать, как используется код. Если есть вопросы о том, как использовать библиотеку, которую вы написали, вместо того, чтобы повторять свои объяснения снова и снова, вы можете просто направить своих коллег на тесты, которые вы написали, чтобы показать, как они используются.
"Побочная" выгода от этого заключается в том, что теперь, если кто-то внесет изменения в вашу библиотеку, вы будете знать, когда она сломается.
Я ни в коем случае не выступаю за экономию на документации, однако в реальном мире...вещи должны быть сокращены, и документация-это одна из них, пока не появится время.
4) настройте сервер сборки с самого начала (например, Team City) и попросите его построить ваш код на checkin. Вы сразу же узнаете, когда сборка сломается.
5) Организуйте свои файлы javascript логически и подчеркните возможность повторного использования. Не вставляйте код непосредственно в представление (в пределах разумного). Очевидно, у вас будут такие вещи, как $(function() { MyJsFile.runFunction ();});, но не вставляйте весь код функции javascript/jquery в представление.
Поощряйте повторное использование и абстрагируйте его в файл, пишите Плагины/JS-модули.
6) Следите за своим техническим долгом. Не "должны" больше, чем можете "отплатить".
---
Есть, вероятно, гораздо больше лакомых кусочков вещей, которые я бы сделал по-другому, но это одни из лучших.
neetugreat2002222222222
Спасибо Дэвид
Это определенно поможет мне в будущем.
На самом деле это будет мой первый проект в качестве ведущего, и я буду разрабатывать и управлять им вместе с еще одним разработчиком.
Изначально проект будет начинаться с 2-х разработчиков, а позже его размер может увеличиться.
Это первый раз, когда я работаю над проектом с нуля и немного взволнован и немного нервничаю. Так хочется быть готовым ко всем препятствиям.
Спасибо