Application d'entreprise dans .NET

Question

pouvez-vous me donner un coup ou m'expliquer comment créer Enterprise App dans .net, et comment type de projets utiliser ou comment devrait être la structure de ces projets? Je suis novice en EE et j'ai lu à ce sujet, mais pour moi c'est la meilleure explication sur un exemple du monde réel. Mon idée de la structure de la solution EE en .net est que:

• données Tier (type de projet => bibliothèque de classe)

  classes d'accès aux bases de données
  • certains cartographes (je ne suis pas sûr si je pouvais utiliser modèle de mappeur de données ou autre? est-ce une bonne idée?)

• Bussiness Niveau (type de projet => bibliothèque de classes)

  • entités qui wil LBE cartographié dans le mappeur de données dans le niveau
  • et une logique d'application
  • de niveau de service (je ne suis pas sûr si elle doit être de niveau individuel, ou subtier de niveau bussiness - Je veux utiliser WCF)
• client (type de projet => WebForms/Android/WPF/....)
  • sera communiquer avec niveau bussiness sur WCF

Mon idée est bonne? Je serai reconnaissant pour toute explication ou indice comment les modèles pourraient utiliser en respectant mes connaissances. J'ai des conditions pour employer 2-3 modèles, parce que le projet d'école est. Merci pour les réponses

Answer 1

Pour la couche de données je voudrais aller avec le modèle de référentiel et le modèle d'unité de travail. C'est vraiment une bonne façon d'abstraire la couche de données et de créer un code testable qui peut être facilement testé à l'unité.

La couche métier dépend, par DDD business doit être encapsulé dans un modèle de données riche. Le modèle de données anémiques est considéré comme anti-pattern. Mais un modèle personnellement riche peut conduire à la ruine du paradigme de la séparation des préoccupations. Parfois, il est utile d'avoir un modèle de données anémiques et une couche de gestion au-dessus de ce modèle. Comme les gestionnaires où chaque gestionnaire fait exactement une action ...

En plus de la couche de gestion est généralement couche d'application qui expose l'interface à l'extérieur, à vos clients. Il devrait être très mince sans aucune logique métier. Peut-être que api Restful qui vous permettra de connecter différents clients comme Android, WFP, Javascript ...

Answer 2

Une mise en œuvre que j'ai trouvé très utile est:

• données Couche d'accès:
  • Entity Framework: Unité de travail
  • Pattern Repository
• couche d'affaires
  • Cette couche des entités des cartes et des appels db à DTO
• Présentation couche
  • Ici vous présentez votre DTOS en utilisant MV? ou tout autre modèle

Il vous utilisez au moins 4 modèles de conception.