创建Model类还是坚持使用通用数据库实用工具类更好?
我们内部有一个简单的实用程序类,用于数据库调用(围绕ADO.NET的轻包装器),但是我正在考虑为每个数据库/对象创建类。这样做是明智的做法,还是只有在我们将完整的MVC框架用于ASP.NET时才受益?
所以我们有这个:
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();
这会很聪明吗,还是会造成过大杀伤力?我可以看到重用,更改数据库和维护/可读性的好处。
解决方案
回答
绝对不是MVC是Web的唯一设计模式,但是它是有用的。
我认为,即使我们不能/不会采用" V"或者" C",仅采用" M"也将带来收益。
回答
这个问题是加载的,数据驱动的设计与域驱动的设计。对于具有大量行为的任何应用程序,则应首选域驱动设计。报告或者实用程序应用程序在数据驱动的设计中往往可以更好地工作(或者更快地开发)。
我们要问的是"我的公司应该在我们设计代码的方式上进行根本性的转变吗"。作为一个领域狂,我的直觉是大声疾呼。但是,由于我们问题的简单性质,我不确定我们是否完全了解我们提出的更改的范围。我认为我们应该与团队讨论更多。
获取一些文献,例如Evan的DDD书或者免费的基础电子书,然后我们将可以更好地判断应该朝哪个方向前进。
回答
对我来说,我们似乎正在尝试执行LINQ已经可以为我们完成的任务。如果我们无法使用旧的框架,我建议我们使用Subconic(http://subsonicproject.com/),而不必手动手动创建所有这些模型对象。
我有一个项目,当时我处在类似的困境中,并在中途改变为亚音速工作,并取得了出色的效果。更快的开发和更容易阅读/使用的代码。
回答
我们所讨论的方法被许多人(包括我在内)认为是一种好方法!学习这种方法将需要一些努力,但是不要让这让我们失望!
只用LINQ to SQL尝试一个小项目怎么办?也许可以在Google代码上找到一个不错的参考项目,并研究其他人如何使用它。
这是一个简单的工具,可让我们熟悉将对象映射到数据库时遇到的一些问题。
然后,我们将能够体会到它,并确定它是否值得学习。
将有一些新概念需要掌握和尝试,例如:
- 工作单元:执行"保存和删除"等操作时,ORM往往不会立即执行此操作,而基于记录集的DAL会执行此操作。这可能令人惊讶,因此我们需要对此有所了解。阅读工作单元模式以了解这一点。
- 批量操作是OR / M的问题。数据读取器可以有效地遍历数千行,但是使用ORM时,在处理大量对象时必须要小心。再次,继续阅读。
- 协会在可以做诸如" customer.Orders.Count"之类的事情时看起来很棒,但是它们也是许多问题的原因。使用关联时,我们需要找到一些安全的操作规范。
...仅举几例
对于初学者来说,不必担心继承和东西,只需简单地开始并具有映射到表的简单实体即可。
尝试以与使用现有DAL相同的方式使用它们。然后开始尝试关联。
然后也许尝试在实体中增加行为。如果我们开始喜欢此方法,并且感觉需要更多功能,请考虑尝试使用功能更丰富的ORM,例如Lightspeed或者NHibernate。
希望这可以帮助!