相关疑难解决方法(0)

我只是掌握了MVC框架,我常常想知道模型中应该有多少代码.我倾向于有一个数据访问类,其方法如下:

public function CheckUsername($connection, $username)
{
    try
    {
        $data = array();
        $data['Username'] = $username;

        //// SQL
        $sql = "SELECT Username FROM" . $this->usersTableName . " WHERE Username = :Username";

        //// Execute statement
        return $this->ExecuteObject($connection, $sql, $data);
    }
    catch(Exception $e)
    {
        throw $e;
    }
}

我的模型往往是映射到数据库表的实体类.

模型对象是否应具有所有数据库映射属性以及上面的代码,或者可以将实际上数据库工作的代码分开吗？

我最终会有四层吗？

我真的很困惑,我用"Apress pro Asp.net Mvc 4"这本书了解到,Mvc 4的最佳模式是依赖注入,(将数据库的模型数据等放在另一个项目中) (域)然后为这些接口创建接口和实现,然后使用Ninja将其连接到控制器.

并且所有与数据库的连接仅来自数据层解决方案,这是viewModel中Web解决方案中唯一的模型

控制器

public class ProductController : Controller
{

    private IProductRepository repository;

    public ProductController(IProductRepository productRepository)
    {
        this.repository = productRepository;
    }
    ....
}

和Ninject

 ninjectKernel.Bind<IProductRepository>().To<EFProductRepository>();

另一方面,在我的上一份工作(网站管理员)中,公司使用了另一种模式用于mvc项目(我现在正在使用这种模式).

这些项目只使用One Solution并使用Static Classes来处理数据层

我不喜欢依赖注入,这太复杂了,'f12'你只看到了接口而不是Concrete类

一些问题:

1. 哪种模式更适合性能(快速网站)？
2. 不好用"public Db db = new Db();" 在控制器中,而不是仅在域层(解决方案)中使用它？
3. 使用依赖注入有什么好处？使用我的模式是不是很糟糕？
4. 将项目拆分为数据层的2个解决方案有什么好处？

例:

 public class LanguageController : AdminController
    {
         public Db db = new Db();

        protected override void Dispose(bool disposing)
        {
            db.Dispose();
            base.Dispose(disposing);
        }

        //
        // GET: /Admin/Language/
        public ActionResult Index()
        {
            return View(db.Languages.ToList());
        }

        [HttpPost, …

毫无疑问，我知道控制器和模型的用途。但是，我能够编写与我的数据库交互的代码，例如在控制器或模型上将用户添加到表中。我应该在什么时候在控制器和模型中编写代码？即使两者都有效，什么是更有条理或更实用的方式。如果答案模棱两可，请您发布示例吗？谢谢