Если не использовать MVC в веб-приложении?
Я не знаком с Платформой Объекта и классом ObjectQuery, но если Включать метод является виртуальным, можно дразнить его как это:
// Arrange
var customerSourceStub = MockRepository.GenerateStub<ObjectQuery<Customer>>();
var customers = new Customer[]
{
// Populate your customers as if they were coming from DB
};
customerSourceStub
.Stub(x => x.Include("Order"))
.Return(customers);
var sut = new CustomerService(customerSourceStub);
// Act
var actual = sut.GetCustomerById(5);
// Assert
Assert.IsNotNull(actual);
Assert.AreEqual(5, actual.Id);
6 ответов
Я думаю, что MVC применим почти повсеместно в веб-приложения, которые мы видим сегодня. Но это не так Это означает, что используемый вами фреймворк всегда поддерживает те типы вещей, которые вы хотите делать.
MVC - это просто шаблон, который хорошо применим к сети. В частности, это хорошо относится к идее, что доступ к приложению осуществляется следующим образом:
- Пользователь запрашивает некоторый ресурс
- Некоторые базовые данные извлекаются откуда-то.
- Затем к этим данным в чтобы показать это пользователю.
Это, несомненно, способ работы сети, однако большинство фреймворков Web MVC исходят из предположения, что каждый пользователь производит относительно мало запросов, запрашивающих большие блоки ресурсов за раз. Я обнаружил, что по мере того, как веб-сайты перемещаются чаще и меньше запросов в стиле AJAX, многие фреймворки требуют некоторой работы, чтобы заставить их хорошо работать, потому что все больше и больше части MVC, относящейся к просмотру, необходимо обрабатывать на клиенте. Поддержка фреймворка для этого далеко не так развита, как для представлений на стороне сервера. Однако центральная парадигма не сильно меняется, и центральный цикл запрос-запрос-шаблон все еще существует.
Вкратце: MVC - хороший способ подумать о том, как работает ваше приложение, но это не значит, что вы собираетесь чтобы найти заранее написанную структуру, которая удовлетворяет все ваши потребности.
Когда это одностраничное приложение .
(на самом деле все же стоит разделить задачи и сделать MVC в малом, но это не MVC в смысле сервера PHP)
По сути, MVC хорошо работает, когда у вас есть приложение, которое требует разделения данных (модели), обработки данных (контроллера) и представления данных (представления). Это также хорошо работает в приложении, где источник данных и / или представление данных могут быть изменены в любое время. Таким образом, данные могут поступать из БД, RSS-канала, Twitter API и т. Д. И могут быть представлены в виде RSS-канала, обычного XHTML, мобильной версии и т. Д. Разделив приложение на три уровня, вы можете разработать для всех этих различные сценарии, просто создав соответствующее представление или модель.
В большинстве случаев веб-сайт / приложение несколько естественным образом вписываются в этот шаблон; частично также из-за популярности шаблона в последнее время, некоторые просто используют его, не задумываясь.
Я действительно не думаю, что это прямой ответ на вопрос " Помните, что MVC - это шаблон проектирования, поэтому это возможное решение в определенных обстоятельствах. Существуют и другие шаблоны проектирования для других обстоятельств, которые могут лучше подойти вашему приложению. Вот ссылка на несколько хороших статей, вводящих шаблоны проектирования, а затем переход к некоторым из основных.
Помните, что MVC - это шаблон проектирования, поэтому это возможное решение в определенных обстоятельствах. Существуют и другие шаблоны проектирования для других обстоятельств, которые могут лучше подойти вашему приложению. Вот ссылка на несколько хороших статей, вводящих шаблоны проектирования, а затем переход к некоторым из основных.Я недавно задавался вопросом о том же. Я уверен, что есть очевидный ответ, кроме того, что это простое и действительно маленькое приложение, в котором MVC было бы излишним. Мне кажется, что разделение представления и бизнес-логики является лучшей практикой.
Чтобы дать обобщенный ответ на общий вопрос:
Сначала заставить его работать , , затем сделать правильным , затем сделать его быстрым .
http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
Это ставит более конструктивную точку зрения на то, что «преждевременная оптимизация - корень всего зла».
Таким образом, параллельно с ответом Джона Скита, адекватная производительность ( как часть того, чтобы заставить что-то работать и делать это правильно) всегда важно. Даже в этом случае его часто можно решить после других функций.
Джеффри Палермо (один из авторов ASP.NET MVC в действии ) опубликовал в блоге сообщение, в котором обсуждается именно это:
Вы НЕ должны использовать ASP.NET MVC, если. . .
Он заявляет, что вам НЕ следует использовать ASP.NET MVC, если:
- Вам не очень нравится полиморфизм
- Вы не желаете строить поверх инфраструктуры
- Вы полагаетесь на стороннюю элементы управления поставщика для большого количества пользовательского интерфейса
- . Вы не склонны использовать библиотеки с открытым исходным кодом
. Я думаю, что большой «стопор» в этом списке может быть положен на сторонние элементы управления (в частности, замены GridView и т. не очень хорошо взаимодействуют с платформой MVC (т. е. элементы управления внутри используют Viewstate и / или Postbacks). Возможно, вы работаете в компании, которая требует использования некоторых сторонних элементов управления для обработки определенных функций веб-компонента (наиболее очевидны элементы управления в стиле GridView или календаря), а не «встроенный» ASP. Элементы управления .NET, которые предоставляют аналогичные функции. Действительно, многие из более сложных встроенных элементов управления на основе ASP.NET WebForms не так хорошо работают с моделью MVC из-за их зависимости от состояния просмотра / обратной передачи и других неподдерживаемых функций модели MVC).
Кроме того, если Приложение ASP.NET, которое вы создаете, невероятно маленькое и тесно сфокусировано на одной функции, его можно было бы быстрее разработать с использованием более «традиционной» платформы WebForms, чем MVC, однако для чего-то большего (т.е.
Честно говоря, я не могу придумать ни одного сценария, в котором было бы нецелесообразно использовать подход MVC. Это всего лишь концепция - методология, позволяющая разделять четко разные части вашего кода логическим и стандартизированным образом.
Codeigniter - превосходный фреймворк. Я использовал его несколько раз. Лучшее в этом, ИМО, это то, что вам не нужно придерживаться строгих правил, которых заставляют придерживаться некоторые другие фреймворки. Codeigniter предлагает вам способ сохранить ваш код организованным, эффективным и безопасным, но, честно говоря, вы можете писать в нем все, что захотите.
Не могли бы вы объяснить немного подробнее, что вы имеете в виду, когда говорите:
». ..и понял, что я немного трудности с размещением вещей фреймворк MVC »
Я действительно хочу помочь вам принять правильное решение. Прямо сейчас отказ от Codeigniter мне кажется плохим решением, основанным на невинном неправильном представлении о том, для чего он нужен.