我一直在阅读NHibernate和Microsoft的实体框架,以针对我的数据访问层执行对象关系映射。我对使用已建立的框架来执行ORM的好处感兴趣,但我很好奇将其用于标准XML序列化和反序列化的性能成本。
现在,我在Oracle和SQL Server中开发存储过程,它们使用XML Types作为输入或输出参数,并根据需要返回或分解XML。我使用自定义数据库命令对象,该对象使用泛型将XML结果反序列化为指定的可序列化类。
通过使用泛型,xml(de)序列化和Microsoft的DAAB的组合,我有一个相对简单的过程,无论数据源如何都可以开发。此外,由于我专门使用存储过程来执行数据库操作,因此我几乎不受数据结构变化的影响。
这是我一直在做的过于简化的例子。
static void main() {
testXmlClass test = new test(1);
test.Name = "Foo";
test.Save();
}
// Example Serializable Class ------------------------------------------------
[XmlRootAttribute("test")]
class testXmlClass() {
[XmlElement(Name="id")]
public int ID {set; get;}
[XmlElement(Name="name")]
public string Name {set; get;}
//create an instance of the class loaded with data.
public testXmlClass(int id) {
GenericDBProvider db = new GenericDBProvider();
this = db.ExecuteSerializable("myGetByIDProcedure");
}
//save the class to the database...
public Save() {
GenericDBProvider db = new GenericDBProvider();
db.AddInParameter("myInputParameter", DbType.XML, this);
db.ExecuteSerializableNonQuery("mySaveProcedure");
}
}
// Database Handler ----------------------------------------------------------
class GenericDBProvider {
public T ExecuteSerializable<T>(string commandText) where T : class {
XmlSerializer xml = new XmlSerializer(typeof(T));
// connection and command code is assumed for the purposes of this example.
// the final results basically just come down to...
return xml.Deserialize(commandResults) as T;
}
public void ExecuteSerializableNonQuery(string commandText) {
// once again, connection and command code is assumed...
// basically, just execute the command along with the specified
// parameters which have been serialized.
}
public void AddInParameter(string name, DbType type, object value) {
StringWriter w = new StringWriter();
XmlSerializer x = new XmlSerializer(value.GetType());
//handle serialization for serializable classes.
if (type == DbType.Xml && (value.GetType() != typeof(System.String))) {
x.Serialize(w, value);
w.Close();
// store serialized object in a DbParameterCollection accessible
// to my other methods.
} else {
//handle all other parameter types
}
}
}
我正在开始一个严重依赖数据库操作的新项目。我很想知道我目前的做法是否可以在高流量的情况下持续下去,以及我是否应该考虑切换到NHibernate或微软的实体框架来执行基本上似乎归结为我目前同样的事情做。
我感谢您的任何建议。
答案 0 :(得分:1)
首先,除非您愿意放弃使用存储过程,否则NHibernate不会提供太多好处,而实体框架可能会让您感到沮丧。
在我看来,似乎你正试图重新发明轮子。通过切换使用普遍接受的ORM工具,您可以确信您的项目将在高流量情况下可持续发展(您可以使用NH Prof或{{3}等工具在这里帮忙)。此外,使用ORM将在此过程中提供更多优势,包括在小的加速期后提高可维护性和最终生产力。