Tarefas básicas com Asp.MVC (CRUD)    

Olá pessoal!

Continuando os tópicos básicos do Asp.Net MVC, hoje vou fazer um pequeno cadastro para mostrar como interagir entre View e Controller. Vou procurar fazer tudo manualmente, para que você possa entender como funciona de fato essa intereção. Digo isso porque existem muitas formas de facilitar o desenvolvimento de Views, por exemplo, utilizando HTML Helpers, mas não vou fazer uso deles para que possamos, quando formos falar dos Helpers, entender como é o seu funcionamento.

Para nosso post hoje, vou criar apenas uma tabela no SQL Server Express para armazenar um cadastro de pessoas, como o objetivo é mostrar a Interação Controller/View/Controller, não vou tomar cuidado com validações, nem com um modelo elaborado.

Para começar, vamos criar nossa tabela como abaixo, e criar o acesso aos dados utilizando Entity Framework.

image

image

Feito isso, vamos adicionar um Controller no projeto chamado Cadastro, lembre-se que sempre começamos o desenvolvimento do site MVC adicionando o Controller. Coloquei “site” em negrito, porque muitos podem dizer que é pelo Modelo, ou Domínio, que se inicia o desenvolvimento, inclusive é o que prega as práticas de DDD (Domain Driven Development), mas quero deixar claro que o Modelo (Domínio) de fato é o princípio do desenvolvimento do Projeto, mas quando vamos iniciar o site, o Modelo já deve estar definido, portanto, conhecendo o Modelo você deve iniciar o site pelos Controllers necessários para esse Modelo, entendendo que o Modelo não é para o site, mas para o projeto, pois ele pode ser utilizado para qualquer ambiente. No futuro vou falar um pouco de DDD, visto que no MVC, a sua utilização é extremamente útil.

Adicionando o Controller, vamos marcar as opções para adicionar as Actions de Create, Update, Delete e Details, apenas para facilitar, visto que não é necessário utilizar exatamente métodos com esse nome para realizar o CRUD dos registros. Veja que ele criar algumas Actions com o mesmo nome, o motivo é bem simples:

Como para acessar uma View devemos acessar pela URL o Controller que contem a Action que sabe gerar essa View (por exemplo: http://seusite/Cadastro/Create), algumas Actions precisam se chamadas para renderizar a View e outras para Processar a requisição da View renderizadas anteriormente. Por exemplo: Para criar um novo registro, eu devo invocar a Action Create para renderizar os campos em brancos, dessa forma invocando a Action Create sem parâmetros, que só deve renderizar a View pura, e em seguida, após preencher os campos e clicar no botão Salvar, eu devo invocar a Action Create novamente, porém agora passando as informações que foram preenchidas, chamando dessa forma a Action com parâmetros. Isso é possível porque o motor do Asp.Net MVC consegue diferenciar overloads de métodos de acordo com as informações passadas no corpo da mensagem. Você precisa sempre utilizar essa regra de Overloads para Actions com funções ligadas? Não! No Asp.Net MVC você tem o controle de tudo, e pode usar da forma que achar melhor.

Além de criar as Actions do CRUD, ele também cria uma Action chamada Index, que é a invocada pelo Asp.Net se nenhuma Action form informada na URL. Precisa sempre ter o nome Index? Não! Como eu disse, você pode mudar quase qualquer coisa no MVC, apenas mudando as rotas padrões no arquivo Global.asax.

Abaixo segue todo o código do meu Controller. Você verá que cada método é muito simples:

  public ActionResult Index()
        {
            using (var bd = new bdEntities())
            {
            var query = from pessoas in bd.Pessoa select pessoas;

                //ObjectQuery p = new ObjectQuery("select cod_pessoa,nom_pessoa,des_email,num_telefone from  Pessoa", bd);
                //var resultado = p.Execute(MergeOption.NoTracking);

            
                return View(query.ToList());
            }
        }

      
        public ActionResult Create()
        {
            return View();
        } 

        [HttpPost]
        public ActionResult Create(FormCollection collection)
        {
            try
            {

                using (var bd = new bdEntities())
                {


                    var pessoa = new Pessoa();

                    pessoa.Email = collection["txtEmail"];
                    pessoa.Nome = collection["txtNome"];
                    pessoa.Telefone = collection["txtTelefone"];

                    bd.AddToPessoa(pessoa);
                    bd.SaveChanges();
                }


                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }
        
        public ActionResult Edit(int id)
        {

            using (var bd = new bdEntities()){
                var pessoa = (from p in bd.Pessoa
                             where p.Codigo == id
                             select p).First();
                         
            return View(pessoa);
            }
        }

        [HttpPost]
        public ActionResult Edit(int id, FormCollection collection)
        {
            try
            {
                using (var bd = new bdEntities())
                {
                    var pessoa = (from p in bd.Pessoa
                             where p.Codigo == id
                             select p).First();

                    pessoa.Email = collection["txtEmail"];
                    pessoa.Nome = collection["txtNome"];
                    pessoa.Telefone = collection["txtTelefone"];

                    
                    bd.SaveChanges();
                }

                return RedirectToAction("Index");
            }
            catch
            {
                return View();
            }
        }

        public ActionResult Delete(int id)
        {
            using (var bd = new bdEntities())
            {
                var pessoa = (from p in bd.Pessoa
                              where p.Codigo == id
                              select p).First();

                bd.DeleteObject(pessoa);
                bd.SaveChanges();
                return RedirectToAction("Index");
            }
        }

Você pode excluir a Actions que não foram utilizadas, como Details (não teremos em nosso cadastro e Delete com dois parâmetros, pois o registro será excluído diretamente da lista.

Perceba que alguns trechos de códigos foram repetidos algumas vezes, e obviamente isso não é legal. Para solucionar esse problema, deveríamos criar um Domínio (Modelo) mais elaborado, encapsulando os métodos de pesquisas, mas para simplificar nosso modelo, resolvi fazer assim. Perceba também que alguns métodos recebem como parâmetro a classe FormCollection. Nesse parâmetro é armazenado todos os campos enviados a partir de formulários do HTML para o Controller, como era feito com Request.Form. É daí que leremos as informações fornecidas pelo usuário.

Você pode estar se perguntando: Posso colocar um método de auxilio no Controller, para facilitar a reutilização? A resposta é: não! Lembre que o MVC procura deixar claro o conceito de SoC - Separation of concerns (Separação de Interesses), por isso, todo método dentro de um Controller, tem a intenção de ser um Controlador (Action), e qualquer método (público) que você colocar ali dentro, será uma Action, mesmo que retorno um tipo incompreensivo para o Navagador. Tudo que tenha a ver com regra de negócio, deve ser colocado na camada Model.

Após criarmos nossos Controllers e Actions, vamos criar as Views.

Três actions necessitam ter Views específicas, são elas:

  • ActionResult Index()  - Retornará a lista de registros.
  • ActionResult Create()  - Retornará o formulário de criação de usuário.
  • ActionResult Edit(int id) – Retornará o formulário de edição de usuário já com os dados preechidos.

As demais Actions não precisam de View específica porque elas apenas persistem as informações e redirecionam o usuário para a listagem, criada na Action Index, sendo esse redirecionamento feito através do método RedirectToAction.

Para criar a View, clique no nome do método com o lado direito do método e Add View.

Vamos ver como ficará nossa View de listagem (Index)

    <h2>Lista de Pessoas</h2>
    <table>
		<thead>
			<tr>
				<th>Ação</th>
				<th>Nome</th>
				<th>E-mail</th>
				<th>Telefone</th>
			</tr>
		</thead>
		<tbody>
		<%foreach(var item in ViewData.Model){ %>
			<tr>
				<td><a href="Cadastro/Edit/<%=item.Codigo %>">Editar</a> <a href="Cadastro/Delete/<%=item.Codigo %>">Excluir</a></td>
				<td><%=item.Nome %></td>
				<td><%=item.Email%></td>
				<td><%=item.Telefone %></td>
			</tr>

		<%} %>
		</tbody>
    </table>
    <a href="Cadastro/Create">Novo</a>

Explicando: Estou criando uma tabela e fazendo um foreach no retorno da Action, que sempre fica exposto através da propriedade ViewData.Model. Para criar a coluna com os links de ação, perceba que estou adicionando links, e montando a URL de acordo com a estrutura Controller/Action/Parametros, e o botão para adicionar um novo, passando apenas Controller/Action. O resultado seria isso:

image

Para as duas outras Views, como vou submeter dados ao servidor, preciso criar um formulário, e definir como Action desse formulário, minha Action do Controller que receberá esses dados. Como são no mesmo Controller, posso apenas fornecer o nome da Action, sem passar o nome do Controller. A diferença de uma para outra é que uma eu já preencho os dados, e outra não:

View de Criação:

 <form name="formCadastro" action="Create" method="post">
    <h2>
        Criar novo Contato</h2>
    <p>
        <span>Nome</span><input type="text" name = "txtNome" id="txtNome" /></p>
    <p>
        <span>E-mail</span><input type="text" name = "txtEmail"  id="txtEmail" /></p>
    <p>
        <span>Telefone</span><input type="text" id="txtTelefone" name = "txtTelefone"  /></p>
    <p>
        <input type="submit" value="Salvar" /></p>
    </form>

View de Edição:

 <form name="formCadastro" action="Edit" method="post">
    <input type="hidden" id="hdfCodigo" name="id" value="<%=ViewData.Model.Codigo %>" />
    <h2>
        Alterar Contato</h2>
    <p>
        <span>Nome</span><input type="text" value="<%=ViewData.Model.Nome %>" name="txtNome"
            id="txtNome" /></p>
    <p>
        <span>E-mail</span><input type="text" value="<%=ViewData.Model.Email%>" name="txtEmail"
            id="txtEmail" /></p>
    <p>
        <span>Telefone</span><input type="text" id="txtTelefone" value="<%=ViewData.Model.Telefone %>"
            name="txtTelefone" /></p>
    <p>
        <input type="submit" value="Salvar" /></p>
    </form>

Diferente do WebForm no MVC você pode colocar quantos formulários quiser em uma mesma página, como é normal em qualquer outra plataforma Web, ou mesmo alterar o Action em tempo de execução. Para que as informações aparecem no parâmetro FormCollection, seus controles precisa ter o atributo name definido, pois é de onde o HTTP retira as informações para criar a mensagem (Post ou Get) a ser enviada ao server. No caso das Views acima, estou enviando via POST, como pode ser visto no atributo method do formulário.

Com esses códigos você já tem seu cadastro funcionando. Com certeza, para desenvolvê-lo você levará menos tempo que para ler esse post. Tudo ficou muito rápido e transparente, sem inúmeros arquivos de códigos inseridos pelo Asp.Net como acontece com o WebForm.

Como eu disse, não utilizei nenhum Helper do MVC para gerar HTML, se tivesse utilizado, com certeza o tempo gasto para desenvolver esse cadastro seria ainda menor.

Conclusão

Nesse post procurei mostrar como é simples criar uma página básica de cadastro. Nos próximos posts tentarei mostrar como deixar essa página um pouco mais elaborada.

Clique no arquivo abaixo para baixar o fonte do exemplo

MvcCrud.rar (426,09 kb)

Até o próximo

30. novembro 2010 14:36 by Frederico | Comments (1) | Permalink

Primeiros passos no Asp.Net MVC    

Olá pessoal, depois de uma pequena série preparando o terreno para começar a falar de Asp.Net MVC, finalmente chegou o momento de falar dessa forma de desenvolver Web.

Vou tentar fazer vários pequenos posts sobre este assunto, e hoje será um bem introdutório, tentando falar um pouco da estrutura do MVC, para que quem nunca criou um novo projeto desse tipo possa ir se habituando. Falarei a principio falarei de Asp.Net MVC 2, porém, conforme for se tornando conveniente, falarei das novas funcionalidades do Asp.Net MVC 3, que já está com a segunda Release Candidate publicada.

Então vamos lá!

Criando um Projeto MVC

Da mesma forma que você cria um projeto WebForm, para criar um MVC você deve ir até o Visual Studio, e seguir os procedimentos padrões, apenas escolhendo o tipo certo de site (Clique nas imagens para ampliar):

image

Quando criamos um projeto Asp.Net MVC, percebemos que uma estrutura bem maior do que a de um WebForm é criada, com diversas pastas e subpastas, como mostrado na imagem abaixo:

image

Vamos explicar um pouco sobre isso. Toda aplicação Web tende a ficar extensa, com inúmeros arquivos. No caso do WebForm, você pode organizar isso da forma que achar melhor, criando vários níveis de pastas e sub-pastas. No MVC, isso é um pouco diferente. Com MVC a Microsoft decidiu trabalhar seguindo convenções, e isso é levado a sério ao desenvolver sites MVC. No caso das pastas, a MS convencionou que deveria existir uma pasta com cada tipo de arquivo, que são: Modelos, Visões e Controladores (Model, View, Controllers – MVC). Existem outras pastas, mas o conteúdo delas é também comum ao WebForms, como Scripts e Content.

Lembre-se: Convenção é um termo que você ouvirá muito no mundo MVC.

É possível mudar essa convenção? Sim, mas nem sempre é interessante, na realidade isso será tema de algum próximo post.

Mas de forma geral, os Controllers você pode colocar em qualquer lugar no projeto que ele será encontrado, os Models (os dados da aplicação) também podem está em qualquer lugar, principalmente em outro projeto, como é comum, apenas as Views que, normalmente, você não trocar de lugar, as view sempre estão na seguinte estrutura de pasta: View/{NomeDoController}/{AçãoDoControle}. O que fugir muito dessa estrutura não será encontrado pela engine de View do MVC. E ai está o ponto, se você realmente quiser mudar essa estrutura, você terá que customizar a ViewEngine do Asp.Net MVC (assunto para outro post).

Ainda existe outra pequena forma de mudar a estrutura de pastas, também tema para um post, que a nova funcionalidade, adicionada a partir do MVC 2, que são as Areas, que resumidamente é uma forma de você agrupar “por funcionalidade” a estrutura de pastas Controllers, Models e Views, ou seja, replicando para cada grupo de Controladores, toda a estrutura padrão de pastas.

Agora que vimos um pouco cada pasta da estrutura do MVC, vamos entender no que consiste cada item do padrão Model View Controller na implementação do Asp.Net MVC.

Controller

O Controller no Asp.Net MVC é representado por uma classe que herda da classe System.Web.Mvc.Controller, é o Controller que é a base do endereço que digitamos na URL, e ele que sabe como deve ser a View que deve ser retornada. Um Controller pode retornar várias Views, de acordo com a Ação (Action) definida.

Action são os métodos do Controller que executam alguma ação e retornam uma View específica, utilizando um Modelo (Model) ou não.

Por exemplo, quando criamos um novo projeto, o Visual Studio cria dois Controllers: Home e Account. O Controller Home tem duas Actions, como mostrado abaixo:

public class HomeController : Controller
    {
        public ActionResult Index()
        {
            ViewData["Message"] = "Welcome to ASP.NET MVC!";

            return View();
        }

        public ActionResult About()
        {
            return View();
        }
    }

Cada Action tem uma View relacionada na pasta View/Home, como pode ser visualizado no print abaixo:

image

Não precisa ser sempre assim. Lembre que uma View pode ser qualquer coisa que retorne para um usuário, portanto, pode ser texto simples, arquivo, JSON, comando para o browser redirecionar, enfim, qualquer coisa coisa que pode ser retornada para o Browser. Para deixar isso claro, vamos criar um novo Controller, da seguinte forma:

Clique na pasta Controller –> Add-> Controller e dê o nome de PrimeiroController, conforme prints abaixo:

image

image

Perceba que temos outra Convenção ao criar um controller: Todos devem ter o sufixo Controller, como os atributos devem ter o sufixo Attribute.

Quando criamos um Controller é criado uma Action padrão chamada Index, que é invocado toda vez que não definimos qual ação chamar, então vamos alterar a implementação padrão do método/action Index, para ficar como a seguinte:

public class PrimeiroController : Controller
    {
        //
        // GET: /Primeiro/

        public string Index()
        {
            return "Primeira página!";
        }

    }

Dando F5, vamos digitar /Primeiro após o nome do seu site no endereço e receberemos o retorno de nossa Action Index no Controller Primeiro da seguinte forma (Perceba que não precisamos digitar o sufixo Controller):

image

Neste casso, o controller está retornando todo o conteúdo HTML, que é a nossa View, vamos criar mais uma Action para ver que podemos chamar mais de uma Action dentro de um Controller e ter Views diferentes. Abaixo segue o código da Action, e o endereço http://localhost:50413/Primeiro/BemVindo digitado no endereço IE. Perceba que você pode colocar qualquer código HTML no retorno da View, e neste caso precisamos também colocar o nome da Action, porque agora não estamos chamando a Action padrão:

public string BemVindo()
{
	return "<h1>Minha Página!</h1><p>Olá, seja bem-vindo!</p>"

}

image

Mas calma! Você não precisa ficar digitando HTML em C# dessa forma, porque seria bem cansativo. Para isso você utiliza um ActionResult como retorno. Vamos mudar o tipo do retorno das nossas Actions de string  para ActionResult, e adicionar Views HTMLs para elas, dessa forma ficará mais fácil de controlarmos a geração do HTML. Podemos adicionar uma View clicando em cima do Método da Action e depois em Add View. Vamos fazer isso para os dois métodos. Aparecerá  a seguinte janela:

image

Essa é a janela que você define as informações da View. Vamos conhecê-la com o passar do tempo. Por hoje, precisamos ver apenas que estamos dando o nome da View, que é o mesmo nome da Action, e também estamos dizendo que ela utilizará uma MasterPage (Site.Master). Quanto a MasterPages, o conceito é o mesmo que no WebForm.

Depois de adicionarmos as duas Views, nosso diretório de View ficará assim:

image

Quando trabalhamos com Action do tipo ViewResult, podemos passar dados do controller para view de duas formas: Através do dicionário ViewData, que você pode pode definir qualquer informação, e lê-la a partir da View, ou através de Model, que é a representação dos dados, como você já sabe.

A princípio não existe nada de mais no HTML da View, porém, se você vem do WebForm, deve saber que NÃO EXISTEM NENHUM SERVER CONTROL no MVC. Portanto, você deverá conhecer HTML, se você veio de PHP ou Asp 3, verá que é bem parecido com o que você trabalhava, a principio pelo menos.

Vamos primeiro codificar o Index, tanto Action como View:

Action:

 public ActionResult Index()
        {
            ViewData["Texto"] = "Primeira Página";
            return View();
        }

View:

<asp:content id="Content2" runat="server" contentplaceholderid="MainContent">

    <h2><%=ViewData["Texto"] %></h2>

</asp:content>

Resultado:

image

Agora o comportamento com um Model, e vendo como ser acessado a partir da View, agora com a Action BemVindo. Nesse caso, estou utilizando como modelo um objeto dinâmico,, apenas como exemplo, mas poderia ser qualquer estrutura de dados:

Action:

public ActionResult BemVindo()
        {
            dynamic model = new ExpandoObject();
            model.Texto = "Seja bem-vindo!";
            return View(model);
        }

View:

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2><%=Model.Texto %></h2>

</asp:Content>

Resultado:

image

Perceba que agora  agente não utilizou o View data, mas um objeto chamado Model, que terá as propriedades do seu modelo de acordo com o definido na Action.

No nosso caso, o IntelliSense do Model não funcionou porque o nosso objeto era dinâmico e o tipo da View era dinâmico, como podemos ver na primeira linha da View:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<dynamic>" %>

No próximo post, veremos como fazer Views fortemente tipadas e como isso pode nos ajudar no desenvolvimento.

Bom, acredito que para um primeiro post, apenas introdutório, o que foi passado já é suficiente para você ir fuçando e descobrindo mais coisas do Asp.Net MVC.

Qualquer dúvida estou a disposição.

Até o próximo!

16. novembro 2010 07:18 by Frederico B. Emídio | Comments (1) | Permalink

A plataforma Asp.Net    

Olá Pessoal!

Depois de algum tempo impossibilitado de escrever, retomo minha pequena série introdutória sobre MVC.

Na realidade, no primeiro post, comentei que faria uma séria sobre Web, para que quando fosse falar de Asp.Net MVC, pudesse falar para pessoas que entendesse pelo menos de Web e Asp.Net, para saber onde Asp.Net MVC se encaixa, para quem não se lembra, segue a lista:

Tentarei ser breve nesse post, para que inicie a série sobre Asp.Net MVC o quanto antes.

O que seria o Asp.Net? Asp.Net é um framework da Microsoft para auxiliar o desenvolvimento Web. Entendam como framework, uma coleção de classes que auxiliam na solução de uma tarefa, e que tarefa é essa? Encapsular requisições HTTP, contextos de requisições, respostas HTTP, enfim, tudo do que a web pura é feita.

O Asp.Net faz o trabalho de traduzir as requisições por nós, é uma coleção poderosa de classes, que devemos utilizar para nos comunicar de forma melhor com os protocolos da Internet.

E o que é que podemos fazer com o Asp.Net? Tudo que você pensa que o IIS faz. Como assim? O que o IIS faz, em grande parte (não em todas é claro), é delegar o processamento de certas requisições as classes do Asp.Net. Você pode ver exemplos disso aqui e aqui. Quando geralmente desenvolvemos sites sobre o framework Asp.Net, não estamos utilizando ele diretamente, estamos utilizando outros componentes que rodam sobre o Asp.Net, como o WebForm e o MVC, e por isso chamados de Asp.Net WebForm ou Asp.Net MVC.

Conhecendo a arquitetura do Asp.Net, poderemos criar inclusive um servidor Web, nosso próprio IIS (como mostrado no segundo link acima), poderíamos implementar da forma que quiséssemos esse servidor, inclusive utilizando um servidor Linux, e rodando o CLR sobre o Mono.

Para entendermos um pouco mais sobre isso, vale mostrar uma ilustração:

Diagrama Asp.net

Perceba na imagem acima que Asp.Net é construído em cima do .Net, portanto pode ser utilizado em qualquer contexto onde qualquer classe do framework pode ser utilizada.

Você também deve ter reparado que coloquei três conjunto de componentes que rodam sobre a arquitetura do Asp.Net, e que geralmente é por onde nós alcançamos o Asp.Net de fato. Da mesma forma que esses três conjuntos estão sobre o Asp.Net, e não se complementam nem se anulam, podemos desenvolver novos frameworks que rodam sobre o Asp.Net.

Poderia ter colocado outros quadrinhos no nível superior do diagrama, mas não quis fazer isso pois quis focar apenas em componentes de Web (que auxiliam na construção de sites/tela). O Asp.Net também é um framework de auxilio ao desenvolvimento para internet (que é levemente diferente de simples Web), e poderíamos incluir no diagrama quadros como WebServices, que não é nem Asp.Net MVC, nem Asp.Net WebForms, nem Asp.Net Dynamic Data, é Asp.Net WebServices, que ainda existe, mesmo com o uso muito mais comum de serviços WCF rodando sobre o IIS.

A Microsoft, na atual estrutura do “framework Asp.Net”, decidiu por implementar três paradigmas distinto de aplicações, esses paradigmas não são exclusivos de Web: MVC também é implementado em aplicações Windows, da mesma forma que o WebForms procura levar para o desenvolvimento Web a experiência de desenvolver WindowsForm, e o Dynamic Data procura implementar o conceito RAD (Rapid Application Development) que visa desenvolver aplicações de forma rápida, interativa e incremental.

Como disse, da mesma forma que a Microsoft desenvolveu esses conceitos sobre o framework Asp.Net, nós poderíamos desenvolver outro paradigmas de desenvolvimento sobre o Asp.Net, e nossas páginas seriam servidas pelo IIS sem grandes modificações, afinal, o IIS conhece o Asp.Net, não a implementação específica de cada paradigma de desenvolvimento.

Um exemplo para isso é o MVC#, que procura implementar o padrão MVP, muito utilizado hoje no desenvolvimento Web. É um framework independente, não muito conhecido ainda, mas que mostra as possibilidades de se criar sobre o Asp.Net.

Entendendo como funciona o Asp.Net, as discussões do tipo “O MVC vai substituir o WebForms” devem acabar, pois dá para entender que cada forma de desenvolvimento tem o seu objetivo, quando vamos iniciar o projeto, devemos pensar em qual padrão se aplica melhor para a solução que queremos desenvolver, inclusive devemos analisar o uso do Dynamic Data, que pode resolver muitos problemas simples de forma extremamente rápida. Talvez no futuro eu faça algum post sobre o uso de tipo de Projeto.

Além de dá suporte aos tipos de aplicação que citei acima, outras tecnologias da Microsoft que rodam sobre o Framework .Net também fazem uso da arquitetura do Asp.Net, como o Silverlight em algumas situações ou o WCF, onde podemos utilizar sessões e outras características específicas de desenvolvimento de internet (sobre HTTP).

Para dar suporte ao desenvolvimento Web, a Microsoft também desenvolveu outras pequenas bibliotecas. Um exemplo disso é o Asp.Net Ajax, que pode ser utilizada tanto no lado Servidor (exclusivo para aplicações Asp.Net, mas exclusivamente para WebForms), como no lado cliente (podendo ser utilizada em qualquer arquitetura web, como Java, PHP, etc) codificada em JavaScript, que já parece estar com os dias contatos, com a adoção cada vez mais ampla pelo time da Microsoft do JQuery.

Bom, acredito que o que foi dito até aqui já dá para ter uma idéia de como o Asp.Net é divido, e como podemos usá-lo de acordo com a nossa necessidade para cada momento. Espero que esse texto possa te ajudar a ver o Asp.Net de uma forma mais ampla, e não apenas fechado a realidade que você trabalha (MVC ou WebForm em geral).

Até o próximo post.

8. novembro 2010 06:38 by Frederico | Comments (2) | Permalink

Sobre mim

Minha Imagem

Meu nome é Frederico Batista Emídio, trabalho com desenvolvimento de sistemas profissionalmente a oito anos, porém, já faço sites pessoais a pelo menos dez anos.

Para saber mais clique aqui.

Páginas

Calendário

<<  novembro 2017  >>
seteququsedo
303112345
6789101112
13141516171819
20212223242526
27282930123
45678910

Visualizar posts em um Calendário
Sigua @fredemidio

MCP Asp.NET