Mon objectif est d'avoir une application qui utilise WPF et est une architecture de 3 niveaux. UI, BLL et DAL ... J'aimerais utiliser le MVVM mais je ne sais pas comment cela fonctionne avec une architecture de 3 niveaux ou si elle est quelque chose de tout à fait différent. Donc, avec cela à l'esprit, j'ai quelques questions:
1) Linqtosql: J'ai lu beaucoup en ligne qui disent que Linq remplace votre DAL et vu de nombreux articles qui disent une mauvaise idée. Je pense que c'est une mauvaise idée, cependant, que dois-je mettre ici? Quels sont les types de données que je retourne au BLL? Iquéry? Observablecollection? Je n'ai aucune idée.
2) Le BLL: J'aimerais faire un service qui fonctionne sur un serveur, de sorte que lorsque je dois faire une modification, je n'ai pas besoin de redéployer toute l'application, j'ai juste besoin de redémarrer le service. . Mais je ne suis pas sûr de savoir où commencer à cela.
3) avec le BLL, je suppose que je suis confondu sur la manière dont les données suivent toutes les couches de la DAL jusqu'à l'interface.
J'ai fait beaucoup de recherches en ligne et j'ai des morceaux et des morceaux de choses, mais je n'ai vu personne parler d'une application WPF utilisant MVVM avec Linq dans le DAL à l'aide de SQLMetal et une BLL qui fonctionne sur un serveur. Est-ce que quelqu'un peut-il me montrer la bonne direction? Ou peut-être un livre pour obtenir?
4 Réponses :
Je vais essayer de donner un aperçu, bien que je ne suis pas un expert, j'ai abordé ces problèmes dans le passé.
linq à SQL est en fait assez bon à ce qu'il est censé faire - ce qui remplace votre dal. Mais ne retournez pas d'Iquériable vers le haut à votre BLL, car cela permettrait (ou au moins indiquer la possibilité) de faire appel à votre dB directement. Vous devez transférer l'objet de données sur la BLL et la laisser construire un objet métier correspondant. BLL en tant que service est un choix naturel. Fournissez une interface ascendante à la couche de présentation (un service WCF est une bonne option ici).
Le BLL génère des objets commerciaux basés sur des données qu'il reçoit de la DAL. Afin de fournir un bon découplage des couches, vous devez utiliser différentes classes pour vos objets DAL et BLL. Ne créez pas une dépendance entre votre couche de présentation et votre couche de données.
Mike,
Votre question est vraiment cool, je l'aime. Tout d'abord, n'hésitez pas à expérimenter un peu - chacun et chaque projet est différent, il n'y a donc pas de règle unique, qui convient partout. C'est pourquoi je suggérerais de quitter DAL à Linq 2 SQL. Ce grand outil va le gérer, vous n'avez pas à vous inquiéter. Deuxièmement, vous avez mentionné 3 architecture de niveau, mais pourquoi n'y a-t-il pas lieu pour le modèle? Étant donné que tous les modèles sont générés automatiquement (par exemple SQLMetal), vous n'avez pas à vous soucier des mappages non plus. Donc, si vous n'êtes pas encore ennuyé, laissez-moi répondre à toutes vos 3 questions:
Skip Dal et observer votre projet Attention - Si vous avez un sentiment, il manque cette couche - ajoutez-le (il contiendra des requêtes LINQ2SQL). Et la deuxième partie - vous pouvez retourner tout ce que vous voulez, mais il sera préférable que vous utilisiez iEnumerable <> ou iquéryable <> paramétré avec vos modèles.
Mon intuition me dit que vous allez avoir besoin de WCF - dans ce cas, vous devriez être capable d'envelopper entiers (oui, c'est vrai) logique commerciale entier dans un bon contrat et que vous souhaitez. < / p>
C'est le plus facile :) puisque votre couche BLL est en réalité une implémentation d'un contrat (interface), vous pouvez concevoir cette interface pour vous fournir toutes les données dont vous avez besoin. Par exemple:
contrat / interface: et que "toutes les couches" vous parliez de rétrécir à une seule exécution de la requête LINQ2SQL. Si vous avez besoin de plus de logique - placez-le dans cette couche. Je veux utiliser mvvm, quoi maintenant? La réponse est plus simple que vous ne le pensez - préparez simplement vos points de vue et affichez des modèles et simplement à consommer votre contrat-contrat / interface BLL. S'il vous plaît demander si vous avez d'autres questions!
Donc, le "modèle" dans le modèle-View-ViewModel est essentiellement le BLL que je vais envelopper dans WCF?
Pas exactement. Pensez à un modèle comme une couche séparée faite uniquement vers la carte (ou littéralement «modèle») vos données persistantes. En bref: le modèle est un ensemble de classes conçues pour modéliser votre base de données. Depuis que Linq 2 SQL modélise pour vous (c'est simplement brillant), ne vous inquiétez pas pour cela - vous avez toutes les classes de modélisation fournies :) Si vous avez d'autres questions - n'hésitez pas à leur demander.
Hmm ... je suppose que j'ai des difficultés à imaginer les couches. Voyons si j'ai ce droit. En haut, nous avons la vue qui possède un fichier .CS associé qui, idéalement, aucun code ne va là-bas. La vue se lie au point de vue qui est essentiellement un adaptateur pour la vue. (Maintenant, c'est là que je commence à vous perdre), car le modèle est pris en charge par Linqtosql, puis-je mettre une référence / connexion au WCF BLL dans chaque viewModel? Et puis enfin, ayez-vous référence à la référence la DAL? Et le DataContext va dans le DAL?
Oui, vous avez 100% raison. Chaque viewModel peut référencer WCF BLL (vous pouvez penser à quelque chose comme une classe de base de menuLodel pour chaque machine virtuelle de votre projet), bll références DAL (mais si vous en avez besoin d'une - dans d'autres cas, interrogeez simplement vos données persistées directement à partir de la VIA LINQ). La dernière chose (DataContext) - Si vous parlez de vos points de données sur vos points de vue, ils doivent préciser définir des instances de vos mentals de vue. Paramés N'hésitez pas à demander plus de questions :)
Je dois avoir un dal car ce n'est pas à moi. Donc, ma prochaine question est que nous mettons le fichier .dbml dans le DAL; Quelle est la bonne façon de retourner des données jusqu'à la vue de la vue / interface? De la requête à afficher ...
Salut Mike. Je crois que c'est une bonne idée de mettre le fichier DBML à l'intérieur de votre couche de modèle. Ensuite, si vous devez vraiment mettre en œuvre DAL, veuillez envisager de créer des méthodes de base de CRUD pour chacune de votre table de DB: E.G. Table 'Les utilisateurs' ont ses utilisateurs DAL Classdal avec des opérations de base: insérer, sélectionner, mettre à jour, suppression. Étant donné que vous avez créé DAL, vous pouvez utiliser ses méthodes à l'intérieur de la BLL pour créer une logique pour vos tables (par exemple, la méthode "getSerSActiveUsers" semble bonne ici). ViewModel utilise simplement les méthodes de BLL. C'est vraiment si simple :)
Grande question. Je ne pense pas qu'il y ait un endroit qui a toutes les réponses. J'ai eu des questions très similaires lorsque nous commençions un nouveau projet. MVVM n'est vraiment qu'un modèle de présentation et ne se soucie pas de tous les détails tels que vous avez répertorié. Bugnion Laurent a un bon cadre qui colle également ensemble.
LINQ2SQL est cool mais peut être encombrant avec les concepteurs VS08. Jetez un coup d'œil à http://plinqo.com/ à utiliser avec des codesmith pour générer le dal et je pense que ce sera même faire le BLL avec des contrats aussi. Une autre option de génération est Modèles Oleg Sych T4 Un problème que nous Le point DataContext singulier avec LINQ2SQL. Si vous n'avez pas besoin d'être modulaire, ce n'est pas un problème.
Je suis d'accord avec ce que les autres ont dit sur les contrats de données et regardent ce que Plinqo peut générer. Cela peut vous sauver beaucoup de temps.
Les données vont fonctionner à la hausse des objets habituellement. Comme les autres ont dit, assurez-vous de garder un semble entre toutes les couches afin que vous ne possédez pas de dépendances.
Lorsque vous arrivez à la partie MVVM, vous allez ouvrir une nouvelle boîte de vers de vers. Je ne pense pas qu'il y ait encore beaucoup de livres sur MVVM. C'est toujours une nouvelle nouvelle machine.
Grande question, je suis sur les pentes de pépinières de la courbe d'apprentissage du WCF / WPF, donc je suis dans une position similaire à vous. Mes 2 cents:
ne sont pas entrés dans Linq à SQL, je suis une vieille école et utilisais l'écriture de procédures et de vues stockées. Je les utilise actuellement pour peupler des classes DTO - c'est-à-dire des classes sans procédés, il suffit de représenter les données. Je sais que je suis probablement derrière la courbe à ce sujet.
Faites de votre service WCF - Mettez le (s) contrat (s) de service (s) et contrat (s) de données (s) dans leur propre assemblée, vous pouvez ensuite inclure cela dans votre client, où ils deviennent votre modèle ou une partie de celui-ci. .
Dans votre demande client, incluez une référence à l'assemblage contenant les contrats de service et les contrats de données. Les contrats de données deviennent ensuite votre modèle, votre vieilleModels peut envelopper ces modèles et exposer leurs propriétés (implémentez INotifyPropertychangned pour la diffusion de base de données).
J'utilise les services de la programmation des livres O'Reilly, les services de l'apprentissage de la WCF et la programmation WPF que je trouve plutôt bien. Je ne connais aucun livre spécifiquement sur MVVM, mais il y a beaucoup de choses sur le Web.
Pourquoi faire référence à l'assemblage BLL et non à un service Web WCF? Pourquoi WCF est-il nécessaire alors?
"Malheureusement, notre école n'enseigne aucune technologie exclusive" lol