无法使用实体框架 c# web api 连接到我的数据库

Question

我有一个 LogContext 模型：

using System.Data.Entity;

namespace Logging.Models
{
    public class LogContext : DbContext
    {
        // You can add custom code to this file. Changes will not be overwritten.
        // 
        // If you want Entity Framework to drop and regenerate your database
        // automatically whenever you change your model schema, add the following
        // code to the Application_Start method in your Global.asax file.
        // Note: this will destroy and re-create your database with every model change.
        // 
        // System.Data.Entity.Database.SetInitializer(new System.Data.Entity.DropCreateDatabaseIfModelChanges<Logging.Models.ProductContext>());

        public LogContext() : base("name=LogContext")
        {
            Database.SetInitializer<LogContext>(null);
        }

        public DbSet<Log> Logs { get; set; }




    }
}

但是当我尝试在 App_code 下的其他 LogContext 类中引用日志时，我在尝试引用 context.Logs.Load(); 时遇到错误。 “不能用实例引用访问；用类型名限定它”

如何引用和呈现表中的所有行？我究竟做错了什么？ 谢谢

using System;
using System.Collections.Generic;
using System.Linq;
using Logging.Controllers;
using Logging.Models;

namespace Logging
{
    public class LogContext : IDisposable
    {
        private static readonly List<Log> Logs = new List<Log>();

        static LogContext()
        {
            using (var context = new LogContext())
            {
                **context.Logs.Load();**
            }
            //Logs.Add(new Log() { Id = 1, LoggerName = "TESTSYS1", InnerException = "InnerException", LogText = "LogText", ThreadID = 1, StackTrace = "Stack Trace", eLevel = "INFO" });
            //Logs.Add(new Log() { Id = 2, LoggerName = "TESTSYS2", InnerException = "InnerException", LogText = "LogText", ThreadID = 2, StackTrace = "Stack Trace", eLevel = "ERROR" });
            //Logs.Add(new Log() { Id = 3, LoggerName = "TESTSYS3", InnerException = "InnerException", LogText = "LogText", ThreadID = 3, StackTrace = "Stack Trace", eLevel = "WARN" });
        }
        void IDisposable.Dispose()
        {

        }


        public void GetLoggies()
        {
            using (var context = new LogContext())
            {
                foreach (var log in context.GetLogs())
                {
                    Logs.Add(log);

                }
            }
        }

        public Log GetLog(int id)
        {
            var log = Logs.Find(p => p.Id == id);
            return log;
        }

        public IEnumerable<Log> GetLogs()
        {
            return LogContext.Logs;
        }

        public Log AddLog(Log p)
        {
            Logs.Add(p);
            return p;
        }

        public void Delete(int id)
        {
            var product = Logs.FirstOrDefault(p => p.Id == id);
            if (product != null)
            {
                Logs.Remove(product);
            }
        }

        public bool Update(int id, Log log)
        {
            Log rLog = Logs.FirstOrDefault(p => p.Id == id);
            if (rLog != null)
            {
                rLog = log;
                return true;
            }
            return false;
        }
    }
}

Answer 1

坦率地说，问题在于非常糟糕的设计。

1. 您的类在此处与您的上下文具有相同的名称，并且还有一个与您的上下文中的成员同名的成员，即Logs。这是一个关于编译器有多智能的案例​​研究，因为整个事情没有爆炸的唯一原因是因为它能够在给定上下文的情况下从你想要的地方做出某种意义。不过，它可能猜错了，你在某些时候肯定会感到困惑。如果您坚持以这种方式维护它，您应该完全限定您的实际上下文类的所有用途，即new Namespace.To.LogContext()，这样编译器就不会只是猜测。

2. 在上下文中使用using 是一个非常的坏主意。理想情况下，上下文实例应该是请求范围的。除其他外，上下文使用了更改跟踪，当您开始在不同的上下文实例之间传递实体时，您将一头扎进砖墙。相反，您应该将上下文注入此类并将其保存为类中的字段。

3. 实施IDisposable 不是您应该轻易做的事情。有一种非常特殊的方式需要实施，否则实际上弊大于利。

   public class Base: IDisposable
   {
       private bool disposed = false;
   
       //Implement IDisposable.
       public void Dispose()
       {
           Dispose(true);
           GC.SuppressFinalize(this);
       }
   
       protected virtual void Dispose(bool disposing)
       {
           if (!disposed)
           {
               if (disposing)
               {
                   // Free other state (managed objects).
               }
               // Free your own state (unmanaged objects).
               // Set large fields to null.
               disposed = true;
           }
       }
   
       // Use C# destructor syntax for finalization code.
       ~Base()
       {
           // Simply call Dispose(false).
           Dispose (false);
       }
   }
   

   见：https://msdn.microsoft.com/en-us/library/b1yfkh5e(v=vs.100).aspx

   然而，如果你注入你的上下文，这个类将不再拥有上下文，因此甚至不需要实现IDisposable。而且，出于对一切美好事物的热爱，在注入依赖项时不要实现IDisposable。我看到太多的开发人员这样做了，并且由于资源分配不正确而导致出现奇怪的错误。

4. 最后，完全抛弃这个类。您实际上（错误地）在这里尝试创建的是一个存储库，您不需要它。实体框架已经实现了存储库和工作单元模式。正如您在此处的方法中所见，您所做的基本上是从您的方法代理到DbSet 上几乎等效的方法。您给自己买的只是一个现在必须维护的附加层、更多的应用程序代码熵和技术债务。有关为什么这是错误方法的更详细说明，请参阅：https://softwareengineering.stackexchange.com/a/220126/65618