Estou convertendo para os dois. Os dois mundos tem seu lugar garantido. O forte do StrataFrame não é apenas winforms ou webforms, mas sim todo o alicerce que ele irá criar para sua aplicação, tirando proveito de tudo o que o .NET tem a oferecer.

Então, sim, faz sentido converter para winforms, e migrar para a plataforma .NET oferecendo um ambiente rico ao cliente com winforms, e utilizar webforms para aqueles casos de acesso a consultas fora do ambiente local por clientes de seus clientes, por exemplo. E há também o Enterprise Server, que fornece acesso remoto de sua aplicação sem sequer se preocupar com segurança de seu SQLServer, encriptação, compactação, nada. Você pode desenvolver para acesso em sua rede local o tempo todo, e com apenas 2 linhas de código disponibilizar o acesso de sua aplicação remotamente. Há um exemplo que vai junto com o seu trial do SF que demonstra isto, acessando a base local, ou no Texas, ou aqui em São Paulo, te deixando mudar esta conexão em tempo real!!!

Muito grato por seus sábios comentários.



Quando eu finalizar o EXE em Windowsforms, o que terei que instalar nos clientes ? Algum pacote de run-time ou DLL ou algo parecido ? Ou esse .NET framework 2.0 ?



E se eu desenvolver para ASP.NET, o Strataframe precisa estar instalado no meu provedor ?



Sergio

Opa, desculpa a demora, passei o dia fora em cliente hoje.

Quando tiver seu EXE pronto para instalar, vai fazer o "deployment". Há alguns instaladores disponíveis no mercado para te ajudar nesta tarefa, mas pode fazer até na mão se preferir. Copia o EXE e DLLs de sua aplicação, certifica-se de ter o .NET Framework instalado na máquina do cliente e configura o Banco de Dados. Eu uso um instalador que cuida de pré-requisitos e instala tudo para mim, posso te indicar depois se quiser. O StrataFrame tem uma "migration class" que irá instalar o banco de dados e até popular tabelas com dados pré-cadastrados se você quiser.

E não, você não precisa ter o StrataFrame instalado em nenhum cliente em nenhuma situação, a não ser que você vá desenvolver no cliente.

Aproveitando a instrução de Ivan, vale lembrar que você mesmo poderá construir seus métodos para popular o BO de forma customizada, como exemplos abaixo:

// Populando com todos os registros
public void FillAll()
{
    this.FillDataTable("SELECT * FROM TbCadastro")
}

// Populando com filtro no CEP
public void FillByCEP(string nrCEP)
{
    this.FillDataTable("SELECT * FROM TbCadastro"
     + " WHERE NrCEP = '" + nrCEP.Trim() + "'")
}

Você codifica os métodos na 'partial class' que o template cria para o BO.

Então, vamos imaginar que você queira abrir o FORM com todos os registros da tabela carregados no BO. No FORM LOAD inclua:

tbCadastroBO1.Clear()
tbCadastroBO1.FillAll()

Carregar com filtro no CEP, chame o outro método. Por exemplo:

tbCadastroBO1.Clear()
tbCadastroBO1.FillByCEP(txtCEP.Text)

Criar seus métodos na classe do BO garantirá o reaproveitamento do método em qualquer outra classe onde ele estaja instanciado.

Rogério Mauri

---

Ótimo post Rogério!

Oi, obrigado pelas informações



O Filtro de que estou falando, utilizando o exemplo que deu, seria no "resultado" dessa 1a chamada,

SELECT * FROM TBCADASTRO, e não chamar um novo select da tbcadastro, entende?



É como se esse o resultado deste 1o select fosse para uma nova tabela TEMP e eu pudesse usar

filtros nessa TEMP, sem ter que rechamar.



No Fox isso é quase um padrão, muito simples. Não sei como fazer no Strataframe



Grato



Sergio

Ola Sergio.

Dê uma olhada no Help, em "Application Framework / Business Layer / Programmatic Access / Data Navigation / Sorting and Filtering Records within a Business Object".

MeuBO.Filter = "meu_campo = 1"

Depois do seu BO populado, basta você setar o filtro, tão fácil quanto no Fox.