MVC против WebForms [закрыто]
Формат UUID предназначен только для чтения. UUID - это действительно 128-битное число. Рассмотрим, что для строкового формата требуется двойное число байтов, чем 128-битное число при сохранении или в памяти. Я бы предложил использовать номер внутри, и когда его нужно отобразить в пользовательском интерфейсе или экспортировать в файл, используйте формат строки.
Дальнейшее чтение: https: //en.wikipedia. орг / вики / Universally_unique_identifier
8 ответов
Вы не должны произвольно выбирать между одним или другим; не стоит использовать MVC-фреймворк только потому, что это новый ребенок в блоке, и все его хвалят, особенно если вы не чувствуете себя комфортно в использовании веб-форм. Практически каждая существующая система будет использовать более старую, более устоявшуюся технологию, и в этом нет ничего плохого.
Несмотря на то, что структура MVC действительно позволяет разделить проблемы еще проще (в конце концов, это и есть шаблон MVC). для), это также несет ответственность за написание большего количества HTML, и я думаю, что немного большее понимание того, как работает сеть; необязательно необоснованное требование, но вы можете утверждать, что оно немного замедлит вас в первые несколько раз, когда вы приступите к его использованию.
Если честно, я согласен, что веб-формы занимают много незаслуженного флекса. Конечно, в фоновом режиме происходит много магии, и вы получаете меньше контроля над некоторыми выходными данными HTML, но не совсем невозможно стилизовать с помощью CSS (в итоге вы часто используете ! Важный , возможно), и также не невозможно получить некоторое разделение проблем, даже если это не встречает пуристское представление о том, что это могло бы быть. Вы все еще можете написать довольно ужасный код, используя инфраструктуру MVC. Если вы хотите быстро собрать что-то вместе, и вы хорошо разбираетесь в веб-формах, то вы сможете достичь этого очень быстро, и в этом нет ничего постыдного, не так ли?
Это не так. сказать, конечно, что вы должны придерживаться своего оружия и игнорировать MVC либо; это хорошая основа (на самом деле, это очень хорошая структура), и она дает несколько преимуществ, которыми вы, возможно, захотите воспользоваться в долгосрочной перспективе. Вы также должны помнить, что он не отменяет автоматически все, что вы узнали о ASP.NET 2.0; В архитектуре MVC реализована большая часть поддерживающей архитектуры, в том числе такие, как поставщики членства.
В Webforms :
И Viewstate, и Postbacks создали много проблем и усложнили разработку веб-приложений. Многие веб-страницы, имеющие размер Viewstate в сотнях килобайт, иногда влияли на производительность приложений.
Разработчики не имеют элемента управления отображением HTML веб-форм и элементов управления сервером, которые отображают HTML со смешанным встроенным стилем и устаревшими тегами, которые не соответствуют стандартам.
Жизненный цикл страницы веб-формы слишком сложен и имеет тесную связь между всеми вещами в среде ASP.net, и один класс используется как для отображения вывода, так и для обработки пользовательского ввода.
Модульное тестирование - практически невыполнимая задача. Сегодня модульное тестирование очень важно в современной разработке программного обеспечения, особенно когда мы следуем гибким методологиям и практикам. Так как в Интернете нет информации о состоянии, события, обратные передачи и Viewstate не являются хорошим способом.
С помощью asp.net MVC все эти вещи упрощаются
Если эти вещи вам не подходят, и вам нравится использовать веб-формы, следуйте тому, что у вас получается лучше всего. Не пытайтесь починить то, что не сломано.
Более подробную информацию см. В: Блог Шиджу по ASP.net MVC против веб-формы ASP.net
I see the key advantages of MVC as:
- Much cleaner and simpler architecture. No more guessing which event you have handle to hook up your data correctly. No more having to insert a hook to "fix" a data binding problem because the framework doesn't do exactly what you want.
- The framework doesn't get your way as much.
- Decoupled architecture makes much more of the code more easily tested.
- More closely aligned with the architecture of the web. For people coming from a WebForms background this may not seem to be an advantage until you embrace it and design for it instead of trying to write WebForms-like applications in MVC. Fortunately, I had explored Ruby on Rails some before using ASP.NET MVC and had already started to write my WebForms apps in a more RESTful way.
- History/Ubiquity -- despite the fact that Microsoft is just rolling it out, MVC is a well-known and highly respected pattern. It's widely used for lots of web applications in many frameworks. Learning MVC will give you a leg up if you need to switch to a different technology where they are also doing MVC -- say RoR or Java/Struts.
The disadvantages:
- Microsoft's implementation is new and not as mature.
- Few third-party "controls"/plugins for round-trip use -- generic grids and such, though there are lots of plugins on the client-side via jQuery.
- Requires unlearning some paradigms from WebForms to effectively use it.
- The framework doesn't do as much heavy lifting for you; you'll have to learn some Javascript and write more client-side code because the framework won't inject it for you.
Веб-формы работают нормально, и если они вам нравятся, продолжайте их использовать.
Три из больших преимуществ модели MVC, как я ее вижу:
ViewState исчез, что могло бы создать довольно значительное количество трафика по проводам. URL-адреса могут быть переназначены, чтобы означать что-то, как это сейчас в моде. Леса строительные. Я не знаю, лично я думаю, что это сатана и поощряет ужасные привычки программирования, но другие, кажется, думают, что это прекрасная идея.
Это также поощряет правильное разделение между бизнес-логикой и представлением путем применения Model-View-Controller шаблон, но хороший код WebForm в основном тоже может это делать.
Так что, действительно, если вы хорошо справляетесь с накладными расходами WebForms и согласны с уродливыми URL-адресами и не хотите создавать леса, придерживайтесь WebForms.
EDIT О, я упустил одно главное преимущество «чистых» URL. И приложение MVC намного удобнее для SEO. Это также дает вам хороший контроль над HTML, но, честно говоря, я не считаю это большим шагом вперед.
Не я. MVC довольно круто в резюме, но для наших клиентов (тех, кто платит за нашу работу), это не ограничитель показа.
Они обычно хотят, чтобы приложения были правильными, быстрыми и безопасными. Вот и все. Они не захотят менять третий слой клиентской части через три года! Через три года они изменят каждую вещь или вообще ничего.
Слои - это весело для архитектора и для кода, но их создание и обслуживание стоят дорого, и они не имеют отношения к нашим клиентам. MVC довольно крутой, но действительно бесполезный и дорогой.
Если, конечно, вы не разрабатываете приложения для 4 ОС и 3 платформ ... Но тогда вы будете в меньшинстве.
: o)
Я думаю, что отчасти проблема заключается в том, что многие люди не понимают, что MVC не является изобретением M $ и не заменяет веб-формы. Конечно, людям нравятся «новые» вещи, и люди любят швырять словечки, особенно чтобы улучшить свои резюме ...
Наконец, у .NET-разработчиков есть некоторый выбор, и с этим выбором на них возлагается определенная степень ответственности за решения, которые они принимают. Я не удивлен, что многие разработчики веб-форм нервничают по поводу этой ответственности. Раньше этого не было. В конечном итоге это может сделать вас лучшим разработчиком или еще хуже. Теперь дело за вами.
Людям нравились веб-формы, потому что они были лучше, чем ASP (Classic). И да, я уверен, что через 5-10 лет кто-нибудь / группа, намного умнее меня, выработает новую парадигму / модель.
Будьте осторожны с этикеткой овцы, поскольку в некотором смысле, придерживаясь определенного поставщика (веб-форм), вы потенциально можете стать более крупной «овцой».
MVC теперь доступен на различных платформах, а это означает, что ваш потенциал в разработке значимых и стабильных решений проблем может быть значительно увеличен. Или уменьшился. Все зависит от вас. Если вы не готовы к работе, дождитесь, пока ASP.NET MVC созреет. Но не закрывайте свой разум ни на что, особенно на схему, которая очень хорошо установлена!
Я рекомендую прочитать чрезвычайно подстрекательский блог Роба Коннери . Он, конечно, бренчал пальцами на мою боль! Тогда идите и прочтите материал RoR, Cake и Struts. Все это покажет вам видение, которое есть у парней, которые привнесли MVC в .NET (~ иш), и, надеюсь, вдохновит вас на то, чтобы увидеть проблемы по-другому!
This is a stupid discussion - they are different, ASP.NET MVC and WebForms are different technologies! I'm using MVC for all new projects, but when I am faced with a need for RAD I use WinForms, because it is simple and there are a lot of controls already written by gurus.
Stop discussing this. Who wants to understand difference? Just try both technologies and you will understand by yourself.
Здесь было несколько более подробных ответов, поэтому вместо того, чтобы повторять то, что они сказали, я постараюсь сделать свой ответ немного более кратким. Вы не должны обязательно использовать MVC поверх веб-форм, так же как вы не должны использовать веб-формы поверх MVC - они оба являются инструментами и более или менее подходят в разных ситуациях. Я впервые познакомился с MVC несколько лет назад на J2EE, когда .NET только появлялся (я не уверен, что ASP.NET MVC был доступен в то время). Он дает действительно красивую, чистую структуру и дает больше "веб-приложений" (например, запрос / ответ), но вы также можете добавить гораздо больше клиентских функций с помощью AJAX - я сделал несколько действительно забавных вещей, используя AJAX на php. приложение, которое я написал некоторое время назад, и все это можно использовать в MVC.
Есть вещи, которые MVC делает лучше, а некоторые - лучше веб-формы, но если вы не знаете обе технологии, вы не сможете выбрать лучшую для текущего проекта, поэтому, пожалуйста, не делайте этого. себе медвежью услугу - иди и изучи MVC. Даже если вы никогда не используете его напрямую, он все равно может дать вам полезные «теоретические» знания, которые вы сможете применить в других инструментах. Я стараюсь изучить как можно больше разных вещей, поскольку чем больше у меня струн на луке, тем меньше вероятность того, что я не смогу решить проблему (например, в этом приложении php я использовал php, были подключены к некоторой части ASP и даже имели файлы пакетов / сценариев DOS и * NIX, выполняющие определенные функции - каждый инструмент имел свое место и лучше всего подходил для работы, которой он был назначен).
Зная обе технологии, вы не можете выбрать лучшую для текущего проекта, поэтому, пожалуйста, не оказывайте себе медвежью услугу - идите и изучите MVC. Даже если вы никогда не используете его напрямую, он все равно может дать вам полезные «теоретические» знания, которые вы сможете применить в других инструментах. Я стараюсь изучить как можно больше разных вещей, поскольку чем больше у меня струн на луке, тем меньше вероятность того, что я не смогу решить проблему (например, в этом приложении php я использовал php, были подключены к некоторой части ASP и даже имели файлы пакетов / сценариев DOS и * NIX, выполняющие определенные функции - каждый инструмент имел свое место и лучше всего подходил для работы, которой он был назначен). Зная обе технологии, вы не можете выбрать лучшую для текущего проекта, поэтому, пожалуйста, не оказывайте себе медвежью услугу - идите и изучите MVC. Даже если вы никогда не используете его напрямую, он все равно может дать вам полезные «теоретические» знания, которые вы сможете применить в других инструментах. Я стараюсь изучить как можно больше разных вещей, поскольку чем больше у меня струн на луке, тем меньше вероятность того, что я не смогу решить проблему (например, в этом приложении php я использовал php, были подключены к некоторой части ASP и даже имели файлы пакетов / сценариев DOS и * NIX, выполняющие определенные функции - каждый инструмент имел свое место и лучше всего подходил для работы, которой он был назначен). он может дать вам полезные "теоретические" знания, которые вы сможете применить в других инструментах. Я стараюсь изучить как можно больше разных вещей, поскольку чем больше у меня струн на луке, тем меньше вероятность того, что я не смогу решить проблему (например, в этом приложении php я использовал php, были подключены к некоторой части ASP и даже имели файлы пакетов / сценариев DOS и * NIX, выполняющие определенные функции - каждый инструмент имел свое место и лучше всего подходил для работы, которой он был назначен). он может дать вам полезные «теоретические» знания, которые вы сможете применить в других инструментах. Я стараюсь изучить как можно больше разных вещей, поскольку чем больше у меня струн на луке, тем меньше вероятность того, что я не смогу решить проблему (например, в этом приложении php я использовал php, были подключены к некоторой части ASP и даже имели файлы пакетов / сценариев DOS и * NIX, выполняющие определенные функции - каждый инструмент имел свое место и лучше всего подходил для работы, которой он был назначен).