-1
votes

Linq aux entités avec motif de référentiel et EF

J'ai récemment travaillé sur un cadre d'entité et un motif de référentiel, dans la classe de référentiel, j'ai créé une fonction appelée trouvaille, qui prend un prédicat génère l'entité de celui-ci. Voici ma fonction de référentiel. XXX PRE>

Voici ma classe de DTO. P>

public class UsersDao : GenericDao<UsersDo>, IUsers
{
     public UsersDao(DataContext context) : base (context) {}
     ...
}


4 commentaires

Comment connaissez-vous les bons DBST? Le cadre d'entité BTW suit le motif de référentiel par lui-même et Je ne vous suggère pas d'utiliser un motif de référentiel externe car cela entraînera des complexités, des fonctionnalités déficitaires, des bugs non désirés et plus encore. Je peux dire que vous devrez éventuellement passer à contourner votre motif de référentiel


@Simonare a mis à jour ma question, pourriez-vous me donner n'importe quelle référence car je peux utiliser le motif de référentiel EF par défaut, avec l'exemple ci-dessus, j'espère que ma préoccupation serait claire.


Pouvez-vous essayer avec iQuiserable requête = dbset.asquerisery (); ?


@SImonare, cela n'a pas fonctionné, il lance toujours la même erreur.


3 Réponses :


0
votes

Pouvez-vous essayer ceci xxx

------- Testez le code xxx


7 commentaires

Même FirstArdefault ne fonctionne pas, le reste du code était similaire.


J'ai marqué la propriété useridid ​​ comme clé de la DBContext, avez-vous vu cela?


Ouais mais j'ai déjà l'utilisateur marqué comme clé pour mon entité. [touche] public int userid {get; set;} String String Nom d'utilisateur {get; set;}


Dans vous DBContext, avez-vous un DBSet ?


Oui j'ai DBSet


Aussi, j'ai une autre fonction générique t get (ID d'objet) et cela fonctionne parfaitement avec usersDao.get (2) , il ne faut probablement pas être le problème d'enregistrement de l'utilisateur, corriger?


Oui, tu as raison, mais je ne sais pas quoi d'autre je peux faire



0
votes

Je recommande vivement un motif de référentiel simplifié qui vous aidera à se moquer de votre source de données pour tester et de fournir plus de flexibilité. Je ne recommande pas d'utiliser des référentiels génériques, mais plutôt de traiter un référentiel similaire à un contrôleur. (Je sert des données pour un ensemble particulier d'opérations) Cela réduit le nombre de références de dépendance, bien que favorise SRP sur DNRY.

Par exemple: P>

public class OrderRepository : IOrderRepository
{
    private MyDbContext Context
    {
        return _contextLocator.Get<MyDbContext>() ?? throw new InvalidOperation("The repository must be called from within a context scope.");
    }

    IQueryable<Order> IOrderRepository.GetOrders()
    {
        var query = Context.Orders.Where(x => x.IsActive);
        return query;
    }

    IQueryable<Order> IOrderRepository.GetOrderById(int orderId)
    {
        var query = Context.Orders.Where(x => x.IsActive && x.OrderId == orderId);
        return query;
    }

    Order IOrderRepository.CreateOrder( /* Required references/values */)
    {
    }

    void IOrderRepository.DeleteOrder(Order order)
    {
    }
}


0 commentaires

0
votes

Le problème est que UserDoa n'est pas une entité enregistrée dans votre dbcontext.

aussi, xxx

n'est pas nécessaire, je crois. Le problème n'est pas lié à votre référentiel générique. xxx

puis xxx


3 commentaires

Oui, je dispose des utilisateursDO inscrit dans dBContext, j'utilise la première approche du code et basé sur DBContext uniquement il crée une table dans la base de données, et mes tables ont déjà été créées avec succès.


Aussi, j'ai une autre fonction générique t get (ID d'objet) et cela fonctionne parfaitement avec usersDao.get (2) , il ne faut probablement pas être le problème d'enregistrement de l'utilisateur, corriger?


public t get (ID d'objet) {var recherche = context.set (). Rechercher (ID); Si (trouvez! = NULL) retour à la recherche; renvoyer null; }