C# 创建模型类还是坚持使用通用数据库实用程序类更好？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2778/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it better to create Model classes or stick with generic database utility class?
提问by Steve Tranby
We have a simple utility class in-house for our database calls (a light wrapper around ADO.NET), but I am thinking of creating classes for each database/object. Would it be smart thing to do so, or would it only benefit if we were using the full MVC framework for ASP.NET?
我们内部有一个简单的实用程序类用于我们的数据库调用（ADO.NET 的轻量级包装器），但我正在考虑为每个数据库/对象创建类。这样做是明智之举，还是只有在我们为 ASP.NET 使用完整的 MVC 框架时才会受益？
So we have this:
所以我们有这个：
SQLWrapper.GetRecordset(connstr-alias, sql-statement, parameters);
SQLWrapper.GetDataset(connstr-alias, sql-statement, parameters);
SQLWrapper.Execute(connstr-alias, sql-statement, parameters);
Thinking of doing this:
想到这样做：
Person p = Person.get(id);
p.fname = "jon";
p.lname = "smith";
p.Save();
or for a new record -
或创造新纪录——
Person p = new Person();
p.fname = "Jon";
p.lname = "Smith";
p.Save();
p.Delete();
Would this be smart, or would it be overkill? I can see the benefit for reuse, changing database, and maintenance/readability.
这会很聪明，还是会矫枉过正？我可以看到重用、更改数据库和维护/可读性的好处。
采纳答案by Karl Seguin
This question is loaded, data driven design vs domain driven design. For any application that has a good amount of behavior, then domain driven design should be preferred. Reporting, or utility applications tend to work better (or are quicker to develop) with data driven design.
这个问题是加载的，数据驱动设计 vs 领域驱动设计。对于任何具有大量行为的应用程序，应该首选领域驱动设计。通过数据驱动的设计，报告或实用程序往往能更好地工作（或开发得更快）。
What you're asking is "should my company make a fundamental shift in how we design our code". As a domain-freak, my gut reaction is to scream yes. However, by the simple nature of your question, I'm not sure you fully understand the scope of the change you are proposing. I think you should talk more to your team about it.
您要问的是“我的公司是否应该对我们设计代码的方式进行根本性转变”。作为一个领域狂热者，我的直觉反应是尖叫yes。但是，由于您问题的简单性质，我不确定您是否完全理解您提议的更改范围。我认为你应该更多地与你的团队讨论这个问题。
Get some literature, such as Evan's DDDbook, or the free foundations ebook, and then you'll be in a better position to judge which direction you should go.
获取一些文献，例如Evan 的 DDD书或免费的基础电子书，然后您将能够更好地判断应该往哪个方向发展。
回答by Dan
By no means is MVC the only design pattern for the web, but it is a useful one.
MVC 绝不是 Web 的唯一设计模式，但它是一种有用的模式。
Adopting just the 'M' will pay dividends, in my opinion, even if you can't/won't adopt the 'V' or 'C'.
在我看来，即使您不能/不会采用“V”或“C”，仅采用“M”也会带来好处。
回答by James Hall
To me it looks like you are trying to do what LINQ can already do for you. If you are stuck in an older framework in which you cant use that, i might suggest that you use Subconic (http://subsonicproject.com/) instead of having to manually create all these model objects by hand.
对我来说，您似乎正在尝试做 LINQ 已经可以为您做的事情。如果您被困在无法使用它的旧框架中，我可能建议您使用 Subconic ( http://subsonicproject.com/) 而不是必须手动创建所有这些模型对象。
I had a project where I was in a similar predicament and changed to subsonic halfway through with fantastic results. Quicker development and MUCH easier to read/use code.
我有一个项目，我处于类似的困境，并在中途更改为亚音速，结果非常好。更快的开发和更容易阅读/使用代码。
回答by tobinharris
The approach you discuss is considered a good one by many folk, me included! Learning this approach will require some effort, but don't let that put you off!
您讨论的方法被许多人认为是一种很好的方法，包括我在内！学习这种方法需要一些努力，但不要让这让你失望！
What about just trying a small project with LINQ to SQL? Perhaps find a nice reference projecton google code, and study how others have worked with it.
只是尝试一个带有 LINQ to SQL的小项目怎么样？也许在google code上找到一个不错的参考项目，并研究其他人如何使用它。
It's a simple tool, and will let you become familiar with some of the issues that come up with mapping objects to databases.
这是一个简单的工具，可以让您熟悉将对象映射到数据库时出现的一些问题。
You will then be able to get a feel for it, and decide if it's worth the learning curve.
然后您将能够感受它，并决定它是否值得学习曲线。
There will be new concepts to graspand experiment with, things like:
将有新的概念需要掌握和试验，例如：
- Unit of Work: When you execute Save and Delete etc, an ORM tends to not do this immediately, whereas a recordset based DAL will. This can be surprising so you'll need to learn a bit about that. Read up on the Unit of Work patternto get an understanding of this.
- Bulk Operationsare an issue with OR/M. A data reader can efficiently iterate through thousands of rows, but with an ORM you have to be careful when working with large batches of objects. Again, one to read up on.
- Associationsseem great when can do stuff like
customer.Orders.Countbut they are also the cause of many problems. You'll need to find some safe practices to follow when working with associations.
- 工作单元：当您执行保存和删除等操作时，ORM 往往不会立即执行此操作，而基于记录集的 DAL 会。这可能会令人惊讶，因此您需要对此有所了解。阅读工作单元模式以了解这一点。
- 批量操作是 OR/M 的一个问题。数据读取器可以有效地遍历数千行，但是使用 ORM 时，在处理大量对象时必须小心。再读一遍。
- 关联在可以做类似的事情时看起来很棒，
customer.Orders.Count但它们也是许多问题的原因。在与协会合作时，您需要找到一些可遵循的安全做法。
...to name a few.
...仅举几例。
For starters, don't worry about inheritance and stuff, just start simple and have simple entities that map to tables.
对于初学者来说，不要担心继承和其他东西，只需从简单开始，并拥有映射到表的简单实体。
Try using them in the same way you'd use your existing DAL. Then start experimenting with associations.
尝试以与使用现有 DAL 相同的方式使用它们。然后开始尝试关联。
Then perhaps try putting more behaviour in your entities. If you start liking this, and feel that you need more features, consider trying out a more feature-rich ORM like Lightspeedor NHibernate.
然后也许尝试在您的实体中加入更多行为。如果您开始喜欢这个，并且觉得您需要更多功能，请考虑尝试使用功能更丰富的 ORM，例如Lightspeed或NHibernate。
Hope this helps!
希望这可以帮助！
