创建Model类还是使用通用数据库实用程序类更好？
我们有一个简单的实用程序类，用于我们的数据库调用（围绕ADO.NET的简明包装），但我正在考虑为每个数据库/对象创建类。这样做是否明智，还是只有在我们使用ASP.NET的完整MVC框架时才会受益？创建Model类还是使用通用数据库实用程序类更好？
所以我们有这样的：
SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);
这样的思考：
Person p = Person.get(id);
p.fname = "jon";
p.lname = "smith";
p.Save();
或一个新的纪录 -
Person p = new Person();
p.fname = "Jon";
p.lname = "Smith";
p.Save();
p.Delete();
这将是聪明，还是会矫枉过正？我可以看到重用，更改数据库和维护/可读性的好处。
这个问题被加载，数据驱动设计vs域驱动设计。对于任何具有良好行为的应用程序，应该首选领域驱动的设计。报告或实用程序应用程序倾向于使用数据驱动设计更好地开发（或更快开发）。
你问的是“我的公司应该如何在设计我们的代码方面做出根本性转变”。作为一个领域怪物，我的直觉反应是尖叫是的。但是，由于问题的简单性，我不确定您是否完全理解您提议的变更范围。我认为你应该多谈谈你的团队。
获取一些文献，如Evan's DDD书或free foundations ebook，然后您将有更好的位置来判断您应该去哪个方向。
MVC绝对不是Web的唯一设计模式，但它是一个有用的模式。
即使您不能/不会采用'V'或'C'，在我看来，采用'M'将会产生股息。
感谢您的输入，我想我会开始添加/替换'M'！ （以前回答为答案，根据社区规则删除） – 2015-09-05 00:24:52
对我来说，看起来你正在尝试做LINQ已经可以为你做的事情。如果你被困在一个你不能使用它的旧框架中，我可能会建议你使用Subconic（http://subsonicproject.com/），而不必手工创建所有这些模型对象。
我有一个项目，我处于类似的困境，并在梦幻般的结果中变成亚音速。更快的开发和更容易阅读/使用代码。
我正在测试Linq to SQL，因为我写这篇文章的时候，它很棒。看起来像是简单的映射，但它应该足够我需要的任何东西。绝对是应该生成的东西。 – 2008-10-02 16:28:13
你讨论的方法被许多人认为是一个很好的方法，包括我在内！学习这种方法需要一些努力，但不要让你失望！
刚刚尝试LINQ to SQL的小项目？或许在google code上找到nice reference project，并研究其他人如何使用它。
这是一个简单的工具，可以让您熟悉映射对象到数据库的一些问题。
然后您将能够得到它的感觉，并决定是否值得学习曲线。
将会有新的概念来把握和试验，之类的东西：工作的
- 单位：当您执行保存和删除等，一个ORM往往不能马上做到这一点，而一个基于记录集的DAL将会。这可能令人惊讶，所以你需要了解一点。请阅读工作单元模式以了解这一点。
- 批量操作是OR/M的问题。数据读取器可以有效地遍历数千行，但对于使用ORM，在处理大批对象时必须小心。再次，一个阅读。
-
协会似乎很棒，当可以做像
customer.Orders.Count的东西，但他们也是许多问题的原因。在使用关联时，您需要找到一些安全的做法。
...仅举几例。对于初学者来说，不要担心继承和东西，只需简单地开始，并且有简单的映射到表的实体。
请尝试按照您使用现有DAL的相同方式使用它们。然后开始试验关联。
然后尝试在你的实体中放置更多的行为。如果您开始喜欢这一点，并且觉得您需要更多功能，请考虑尝试使用功能更丰富的ORM，如Lightspeed或NHibernate。
希望这会有所帮助！
感谢您的信息，我会研究这些书籍。对不起，我的问题被加载/简单。我不想写太多，可能应该只是询问模型与无模型。我的团队面临的问题是，我在这里是新手，他们正在运行大量和传统的sphagetti Classic-ASP代码，并且在使用ASP.Net的某些功能时仍然以这种方式开发。 （以前回答这是一个答案，已根据社区规则删除） – 2015-09-05 00:24:34