Nous sommes au début d'un nouveau site web en fonction du produit dont nous sommes la planification pour exposer notre logique métier à travers des services WCF. Nous allons utiliser ASP.NET 4.0, C#, EF 4.0. À l'avenir, nous voulons construire des applications iphone et applications WPF, basé sur les services. J'ai lu beaucoup de choses sur l'utilisation de POCO vs Auto Entités de Suivi (STE) et de mon comprendre les STEs ne fonctionne pas bien avec le scénario web. Quelqu'un peut jeter plus de lumière sur cette question?
Réponses
Trop de publicités?
Pour moi STE est absolument faux concept. C'est juste une autre mise en œuvre de l'ensemble de données.
- Dans ASP.NET l'application vous aurez à stocker STEs quelque part entre les demandes. Dans la première demande de vous interroger votre source de données pour obtenir de STE et de fournir des données dans la page. Dans la demande suivante (postback) vous souhaitez modifier STE avec les données renvoyées à partir du navigateur. Afin de faciliter le suivi, vous devrez utiliser la même SAINTE, comme dans la première demande => vous aurez à stocker STE dans viewstate (si vous souhaitez utiliser ASP.NET WebForms) ou de la session.
- STE est inutile pour la SOA ou d'interopérabilité. Logique de suivi fait partie de STE = il est en cours d'exécution sur le client. Si vous exposez STE dans le service, vous êtes immédiatement en attendant que côté client va utiliser les mêmes fonctionnalités de suivi inclus dans STE logique. Mais ces fonctionnalités ne sont pas fournies à d'autres automatiquement. Dans .NET, vous devez d'eux parce que vous partagez assemblée avec des entreprises d'etat. Mais sur d'autres plate-forme, vous devez expliquer comment les développeurs à mettre en œuvre STE logique de le faire fonctionner sur votre côté. Ce sera probablement la plupart des cas limite pour vous en raison de l'application iPhone.
jfar
Points
19380
L'autonomie des Entités de Suivi de fonctionner parfaitement dans un Web MVC avec WCF scénario. J'ai été impliqué dans 2 projets de les utiliser ( une dans la production, un presque ).
Avec POCOs vous perdez tout le suivi des modifications sur le fil qui crée beaucoup de douleur supplémentaire parce que EF a maintenant de re-query pour les informations d'état. Si votre utilisation de l'EF et de la WCF STE de résoudre beaucoup de problèmes et de rendre l'ensemble de votre persistance pipeline très lisse.
Pouvez-vous fournir une citation pour cette demande? "Les entreprises d'état ne fonctionne pas bien avec le scénario web"
Damilola Okuboyejo
Points
31
Reportez-vous à http://msdn.microsoft.com/en-us/data/jj613924.aspxcomme les entreprises d'état N'est Plus Recommandé! Microsoft recommande l'utilisation de l'un quelconque de ASP.NET l'API Web, les Services de Données WCF, ou Entity Framework Api (complexe de la fpo)
Wyatt Barnett
Points
12541
Si ce service va être consommé par n'importe quelle application que vous n'avez pas de contrôle direct, vous devriez probablement envisager sérieusement de divorce, rien à voir avec les objectifs EF (ou nHibernate ou Linq2Sql ou de tout autre persistance des données, la solution de gestion) de vos services et de vos objets de transfert de données. Cela permettra d'isoler les changements internes de rupture les clients. Rupture les clients est généralement une mauvaise chose.
