Melhor lugar para classificar uma lista de tarefas

Question

Im construindo uma aplicação web que é um aplicativo de gerenciamento de processo. Vários tipos de funcionários diferentes será mostrada uma lista de tarefas a fazer e como cada um completa uma tarefa, então, ele é movido para o próximo empregado para trabalhar.

A hierarquia de tarefas é Batch> Carga> Assembleia> Parte> Tarefa. Atualmente 8 regras para determinar quais tarefas devem ser trabalhados em primeiro lugar para cada tipo de funcionário. Estas regras aplicam-se a dimensão da parte, e também como que a conclusão partes afetará a Hierarquia por exemplo, se a parte A é completado, em seguida, ele completa um lote inteiro onde, como parte B não como há ainda outras partes restantes em seu lote para ser concluída.

De qualquer forma essa é a passo do elevador de como funciona o sistema. O que estou tentando descobrir é uma maneira eficiente, rápida e sustentável de fazer isso tendo em mente as regras podem mudar e pode ser adicionado mais regras.

Inicialmente, eu tinha a intenção de deixar o DB (SQL 2005) fazer todo o trabalho pesado, mas eu tenho uma preocupação que as regras mais complicado vai ser difícil de implementar com um DB. Assim, uma alternativa é retirar uma lista de tarefas em uma camada intermediária e criar uma coleção de objetos e aplicar cada uma das regras para a coleção. Eu não tenho nenhuma dúvida de que cada regra poderia ser traduzido para T-SQL isoladamente, mas ordenação por até 8 critérios, dependendo das sente tipo de tarefa como um monte de problemas.

Um benefício que eu posso ver com a abordagem do meio camada é que eu possa criar um sistema mais flexível restrito onde o fluxo de tarefas pode ser alterado, que seria mais difícil no DB eu acho.

Então, o que vocês recomendam? Existe uma terceira alternativa que eu não tenha pensado?

EDIT [1] Só para qualificar este um pouco mais, a DB não se espera mudança do que eu inicialmente desenvolvê-lo em.

Answer 1

É difícil determinar a partir dos dados em questão. No entanto, colocar a sua lógica em uma lógica de negócios da camada (meio) significará que suas regras de negócios pode continuar a usar o mesmo código não importa o que o banco de dados back-end pode ser. No momento em que você especificar T-SQL, mas é possível que no futuro você vai passar para um ambiente de servidor não-SQL?

Answer 2

O que plataforma? NET 3.5 introduz LinqToSQL que podem tornar este um ponto discutível. Você pode usar um padrão de estratégia para selecionar / build uma consulta apropriada com base no tipo de tarefa, então deixe LINQ fazer a tradução para o SQL para você. Dessa forma, você pode construir a consulta no código, mas ainda tem que realmente executado no DB.