Retorna um valor que indica se o item especificado está selecionado.
public bool GetSelected (int index);
Obter o índice:
foreach (int blah in listBox_TipoPeca.SelectedIndices)
{ var indice = blah.ToString(); }
Obter o nome dos itens selecionados:
string tmpStr2 = "";
foreach (var item in listBox_TipoPeca.SelectedItems)
{
tmpStr2 += listBox_TipoPeca.GetItemText(item) + "\n";
var num = listBox_TipoPeca.SelectedValue;
}
MessageBox.Show(tmpStr2);
O objetivo deste bog, não é mostrar como criar a codificação de um repository parttner ou service parttner, mas sim o conceito de forma breve e direta.
REPOSITORY
Martin Fowler define um repositório como:
Um Repositório faz a mediação entre o domínio e as camadas de mapeamento de dados, agindo como uma coleção de objetos de domínio na memória. Objetos de cliente constroem especificações de consulta de forma declarativa e as enviam ao Repositório para satisfação. Objetos podem ser adicionados e removidos do Repositório, assim como de uma simples coleção de objetos, e o código de mapeamento encapsulado pelo Repositório realizará as operações apropriadas nos bastidores.
Conceitualmente, um Repositório encapsula o conjunto de objetos persistidos em um armazenamento de dados e as operações realizadas sobre eles, fornecendo uma visão mais orientada a objetos da camada de persistência. O repositório também suporta o objetivo de alcançar uma separação clara e dependência unidirecional entre as camadas de mapeamento de domínio e de dados.
Um padrão de repositório é um padrão de design que medeia dados de e para o domínio e as camadas de acesso a dados (como Entity Framework Core / Dapper). Repositórios são classes que ocultam as lógicas necessárias para armazenar ou recuperar dados. Assim, nossa aplicação não se importará com o tipo de ORM que estamos usando, pois tudo relacionado ao ORM é tratado dentro de uma camada de repositório. Isso permite que você tenha uma separação mais limpa de preocupações. O padrão de repositório é um dos padrões de design mais usados para criar soluções mais limpas.
O padrão Repository, nos permite criar uma camada de abstração entre o acesso aos dados e a camada de lógica de negócios de uma aplicação. Ao usá-lo, estamos promovendo uma abordagem mais flexível para acessar nossos dados do banco de dados. Além disso, o código é mais limpo e mais fácil de manter e reutilizar. A lógica de acesso a dados está em uma classe separada, ou conjuntos de classes chamados de repositório, com a responsabilidade de persistir o modelo de negócios do aplicativo.
Observe, o argumento é fraco, mas não irreal, como foi muito bem ressaltado por Shawn McCool
“Any sufficiently designed object-oriented application automatically comes with this type of advantage. A very central concept to object-orientation is encapsulation. You can expose an API and hide implementation”
Em outras palavras, o que ele defende é que esse não deve ser o motivo real para a utilização / aplicação do padrão em seus projetos, já que a troca de ORM não acontece assim… num estalar de dedos… e o encapsulamento está ai pra facilitar essa troca, quando esta necessidade realmente existir.
Não podemos afirmar sobre o assunto. Mas pode ser usado quando desejar deixar as coisas mais organizadas e separadas e criar uma barreira (de controle e segurança) entre a aplicação e os seus dados, utilize repositórios. Mas, caso o projeto não necessite usar, não use, pois somente irá irão gerar desperdícios (de tempo, esforço, etc).
Repositório é ser um serviço de domínio, que abstrai a camada de persistência da sua aplicação e atua como API para os serviços de aplicação (controllers, CLI, etc). Ou seja, deve ser a única API de acesso confiável aos objetos de domínio e não deve ser responsável por conexões ao banco, envio de e-mail, etc…
Este é um dos tópicos mais debatidos na comunidade .NET Core. A Microsoft construiu o Entity Framework Core usando o Repository Pattern e Unit of Work Patterns. Então, por que precisamos adicionar outra camada de abstração sobre o Entity Framework Core, que é mais uma abstração do Data Access. A resposta para isso também é dada pela Microsoft.
A própria Microsoft recomenda (conselhor, aviso, advertir) o uso de Repository Patterns em cenários complexos para reduzir o acoplamento e fornecer melhor Testabilidade de suas soluções. Nos casos em que você deseja o código mais simples possível, deve-se evitar o Repository Pattern.
SERVICES
A ideia básica é a seguinte:
As classes Service são projetadas para fazer duas coisas:
O padrão Repository-Service divide a camada de negócios do aplicativo em duas camadas distintas.
O padrão Repository-Service depende da injeção de dependência para funcionar corretamente. As classes em cada camada da arquitetura terão classes de que precisam das camadas "inferiores" injetadas nelas.
Portanto, nossas classes Service serão classes simples de "passagem" para retornar as informações em seus respectivos repositórios.
Por último a Controller fará a Injeção de Dependência da classe de serviços.
O Repository-Service Pattern é uma ótima maneira de arquitetar um aplicativo complexo do mundo real. Cada uma das camadas (Repositório e Serviço) tem um conjunto bem definido de preocupações e habilidades e, mantendo as camadas separadas, podemos criar uma arquitetura de programa de fácil modificação e manutenção.
Um forte abraço a todos e até a próxima
O Dart é uma linguagem de programação pelo Google em 2011 que tinha objetivo substituir o Javascript se tornando a principal linguagem a ser utilizada nos navegadores web. Segundo (CORAZZA, 2018, p. 23), o Dart é uma linguagem moderna, orientada a objetos, concisa e fortemente tipada. Ela é considerada altamente versátil, pois pode ser utilizada em desenvolvimento de aplicativos, desktop, web, criação de scripts e até mesmo no back-end. Possui como característica a capacidade de inferir os tipos, tornando-se opcional a declaração do tipo da variável ao criá-la, visto que a linguagem assumirá o primeiro tipo associado a mesma (DANTAS, 2020).
O Dart é uma linguagem de programação fortemente tipada inicialmente criada pela Google em 2011. A missão inicial do Dart era substituir o JavaScript para desenvolvimento de scripts em páginas web. Porém, com a evolução da linguagem e com o passar dos anos, ela hoje pode ser considerada uma linguagem multi-paradigma, embora a linguagem apresente fortes estruturas típicas de linguagens orientadas a objeto.
Dart possui uma sintaxe com estilo baseado no C. Isso faz com que sua sintaxe seja muito similar à linguagens atualmente populares, como Java e C#. Porém, o Dart tenta reduzir um pouco os ruídos característicos de linguagens baseadas no C.
Com o controle DataGridView, você pode especificar informações de estilo para alternar linhas. Isso permite usar as características de estilo como cor e fonte , além da cor da tela de fundo, para diferenciar as linhas alternadas.
Os estilos usando as propriedades RowsDefaultCellStyle e AlternatingRowsDefaultCellStyle substituem os estilos especificados nas propriedades do DataGridView,
dgvLog.AlternatingRowsDefaultCellStyle.BackColor = Color.LightYellow;
dgvLog.AlternatingRowsDefaultCellStyle.ForeColor = Color.Maroon;
Comunicação síncrona refere-se ao contato imediato entre o emissor (quem envia a mensagem) e o receptor (quem recebe a mensagem), a comunicação assíncrona é atemporal.
Na comunicação assíncrona o emissor envia a mensagem, mas não necessariamente o receptor irá recebê-la imediatamente.
Imaginemos que um emissor está a enviar uma mensagem de texto através de um tubo e que a mensagem é enviada recorrendo a bolas, cada bola com uma letra. Quando as bolas chegam ao receptor, a mensagem tem que ser remontada, ou seja, têm que se colocar as bolas pela ordem correta, para se voltar a ter a mensagem.
Em uma comunicação síncrona o emissor e receptor são sincronizados pelo mesmo relógio, o receptor recebe de modo contínuo (mesmo quando nenhum bit é transmitido) os dados em compasso em que o emissor as remete.
Simples exemplo em Javascript:
function foo(){
console.log("foo");
}
function bar(){
console.log("bar");
}
function baz(){
console.log("baz");
}
foo();
bar();
baz();
Essas funções serão executadas em ordem, bar não será executada até que foo tenha terminado e baz por sua vez só será executado após o término de bar, havendo assim uma sincronia.
Em uma comunicação assíncrona a sincronização é diferente, o emissor envia o fluxo de dados e periodicamente insere um elemento de sinal, comumente chamado de flag, para que seja possível distinguir aonde começa (a informação de início da transmissão é o start-bit) e acaba (a informação de fim de transmissão é o stop-bit) o bloco de dados e qual a sua posição na sequência de dados transmitidos.
Exemplo:
function foo(){
console.log("Executando algo assíncrono aqui");
}
function bar(){
setTimeout(foo, 0);
console.log("Alguma coisa por aqui");
console.log("...");
}
bar();Aqui não há a mesma sincronização que noutro exemplo, uma função não vai esperar pelo término da outra. Nesse exemplo usamos a função setTimeout para enfileirar foo que vai executar 0 ms após o loop de eventos, o loop de eventos ficará indisponível até completar sua atual pilha de execução - neste caso, o resto de bar, que inclui as duas declarações console.log. Após o término de bar o loop de eventos fica livre, e assim foo pode ser executada.
Saída:
Alguma coisa por aqui
...
Executando algo assíncrono aqui
Quando e para que devo usá-las? Grande parte do processo de tomada de decisão sobre isso envolve o senso comum, um conjunto de fatores, uma comunicação assíncrona pode ser usado quando a resposta não tenha que ser entregue urgentemente, esse tipo de comunicação é adequado para situações em que não seja necessário a entrega urgente dos dados, por outro lado, não seria apropriado usar esse tipo de comunicação se você precisa de interação imediata. Já a comunicação síncrona é ideal quando se precisa de espontaneidade, como em uma conversa em tempo real entre duas ou mais pessoas.
Tanto a comunicação síncrona, quanto a assíncrona, têm suas vantagens e desvantagens, utilizar uma ou outra vai depender da necessidade da sua aplicação.
int indice = dgvTabelaParticulaAdicionar.CurrentCell.RowIndex;
Obtém o índice da linha pai da célula.
É bem simples. Basta definir a constantes que indicam o alinhamento de conteúdo dentro de uma célula DataGridView
dgvTabelaParticulaAdicionar.Columns[6].DefaultCellStyle.Alignment =
DataGridViewContentAlignment.TopRight;