Modèle de conception pour une application pilotée par les données CRUD simple

Question

Je voudrais connaître la meilleure pratique pour concevoir une application CRUD simple avec des écrans mettant à jour diverses tables (comme les pages d'administration pour conserver les données statiques pour une application). le plus simple serait de faire glisser une grille/grille de données, de la lier à un ensemble de données et d'utiliser un adaptateur de données pour les opérations CRUD. mais si cette application doit être évolutive, disons d'ajouter une interface utilisateur/business supplémentaire à l'avenir, alors y a-t-il un modèle de conception qui peut vous aider? devrais-je utiliser un contrôle de source de données d'objet et le lier à des objets métier à la place? ou y a-t-il de meilleures façons de le faire? devrais-je construire une application en couches complète ou est-ce que ce sera surexploitation pour cette exigence? des exemples de conception d'interface utilisateur seraient également utiles. Merci.

Answer 1

Si vous êtes à la recherche d'une approche vraiment rapide et facile, vous pouvez envisager d'utiliser des données dynamiques http://www.asp.net/dynamicdata sur le dessus d'un back-end Linq2SQL ou EF4 - à peine un code nécessaire à tous.

Answer 2

http://www.asp.net/mvc est mon pari. C'est facile de commencer et de partir ... Vous ne serez pas déçu. :) StackOverflow lui-même est construit sur le dessus.

Answer 3

+1 Oded. Aucune offense RKP mais vous pourriez confondre "simple" avec "efficace" ou "valeur-pour-argent". Je pense aussi que vous voudrez peut-être être plus clair sur ce que vous recherchez: les conceptions d'interface utilisateur sont un problème assez différent de l'architecture logique. En tout cas - bien sur vous pour demander.

S'il s'agit d'une solution «tactique»: ne devrait pas avoir une longue durée de vie, ou est un outil de développement rapide et sale, alors la façon dont vous le construisez pourrait ne pas être un gros problème. (attention aussi que les applications tactiques à court terme peuvent devenir des applications stratégiques à long terme - travaillaient sur une application maintenant que l'entreprise considère comme un outil «temporaire»: elles ne la voient utilisée que pour les 5-10 prochaines années (!)). S'il s'agit d'un outil que les «utilisateurs professionnels» utiliseront, il est fort probable qu'ils s'attendent à des changements au fil du temps: en fonction de ce que l'application est pour un simple passage, l'application CRUD peut seulement couper la moutarde pendant un certain temps .

Donc, je suppose que c'est là que votre admirable désir de regarder les meilleures pratiques entre en jeu. Êtes-vous familier avec le design OO? Un grand nombre des principes derrière la bonne conception OO s'appliquent également au niveau architectural (SOLID, Common Reuse, Common Closure, Loose Coupling, Stable Dependancies et Stable Abstraction Principes).

permet de dire d'ajouter une logique UI supplémentaire/business à l'avenir

Alors - c'est là que vous devez considérer à l'avance comment vous séparer les préoccupations et permettre la croissance: l'architecture n » t signifie que vous devez faire une grande conception dès le départ, cela signifie simplement que vous devez avoir une idée de la façon dont vous cultivez l'application que les exigences augmentent ..

pour terminer:

• Observez bien les différents attributs de qualité du système et déterminez ceux qui sont particulièrement pertinents pour le système. les prioriser.
• Je reçois beaucoup de kilométrage sur Dependency Inversion (Le D dans SOLID) - abstraction des choses comme l'accès aux données au début.
• Pour moi, l'autre vraiment clé « meilleure pratique » est de prêter attention à SRP (S en SOLID),