Como organizar melhor vários WebProjects que usam lógica comercial semelhante

5

Temos a seguinte configuração

Current Solution:

  • Business Logic (Class Library)

  • Data Layer (Class Library containing EF,Web Services wrappers etc)

  • WebProject1

MAS agora queremos escrever outro Web Project (Web Project2) que seria quase idêntico ao WebProject1, exceto pelo fato de que ele alteraria propriedades e variáveis de entrada para funções / espaços vazios dentro da classe Business Logic para fornecer um conjunto diferente de dados para outro usuário completamente diferente. (Precisa de reformulação). Pense no Facebook como WebProject1 e Myspace como WebProject2. Mesmo conceito, mesma camada de negócios, quase produtos diferentes.

Future Soltion

  • Business Logic (Class Library)

  • Data Layer (Class Library containing EF,Web Services wrappers etc)

  • WebProject1

  • WebProject2 (similar to WebProject1 but different authentication, different UI, different pages etc)

  • WebProject3 (possible)

Sem destruir completamente a lógica de negócios (já que a classe teria que permitir 2 caminhos por conjunto de variáveis de entrada), como podemos estruturá-la para dobrar o código em qualquer código?

Editar: explicar a lógica de negócios

WebProject1 fornece dados baseados em um filtro de banco de dados chamado "ByCompany"

WebProject2 fornecerá os dados com base em um filtro chamado "BySite Ambos os projetos serão consumidos por diferentes públicos que não saberão que o outro site existe.

Por exemplo, uma possível lógica futura pode incluir algo assim:

BusinessLogic.EmployeeList employeeList = new BusinessLogic.EmployeeList();

employeeList.LoadBySite("ConstructionSiteC");

employeeList.LoadByCompany("JohnDoesTractors");

O dilema é:

Devemos manter duas bibliotecas de classes do Business Logic? Devemos adicionar prefixos aos nomes das classes para denotar seu pai WebProject correspondente? Devemos criar classes base e herdar se houver substituições que precisamos fazer? Devemos criar mais lógica de negócios baseada em interface? Deveríamos ter apenas duas soluções separadas que tiram do mesmo DAL?

Os projetos provavelmente ficarão bastante grandes (em relação à lógica de negócios de 300 classes) e queremos minimizar o máximo possível de duplicatas. Qual é o seu método ou sugestão?

Obrigado!

    
por Jeremy 12.04.2011 / 12:55
fonte

1 resposta

8

except for the fact that it would alter properties and input variables to functions/voids inside the Business Logic class to provide a different set of data for another completely different user

Isso é apenas um erro de design. Nada mais.

Corrija primeiro.

Depois, simplesmente compartilhe a lógica de negócios entre os dois aplicativos da Web.

Should we maintain two Business Logic class libraries?

nunca.

Should we add preffixes to the class names to denote their corresponding WebProject parent?

Não.

Should we create base classes and inherit if there are overrides we need to make?

É por isso que a herança foi inventada.

Faça isso. Faça muito disso.

Should we create more interface based business logic?

Talvez. Interfaces podem ser apropriadas se as classes de lógica de negócios forem muito diferentes.

Should we just have two separate solutions that draw from the same DAL?

Não. Abordagem de nível muito baixo.

    
por 12.04.2011 / 13:01
fonte