One key thing to be aware of here is that if the database schema is changing frequently, you want to have some level of compile time type safety. I've found this to be a problem with NHibernate because it uses xml mapping files so if you change something in your database schema, you don't know until runtime that the mapping is broken.
It will also be a problem with stored procs.
Using Linq2Sql will give you the advantage of knowing where exactly your code is breaking when you change a schema at compile time. This for me, is something that would take precedence over everything else if I'm working with a frequently changing schema
I'd look at SubSonic with the build provider (Website Project) setup. That works great because it automatically regenerates the DAL objects every time you build your project, so if the database changes in a way that breaks your code, you get a build error.
It worked well until the database schema got really complex and we were hitting the limits of the ActiveRecord pattern, but as long as the schema's not hugely complex it works pretty well. Once the schema stabilizes, you can switch so that you're only building the DAL when you want to.
You definitely want to use an ORM. Any ORM is ok, but you want something that will generate strongly typed classes. When fields get added, modified or deleted from a table, you want to be able to regenerate those classes, and deal with fixing compile time errors only. If you use a dynamic model, you're likely to have many nasty runtime errors. This is VERY important! I am part of the MyGeneration development team on sourceforge, and I think that is a great solution to your problem. You can generate dOOdads, NHibernate, EasyObjects, EntitySpaces, etc. If you want to go with a more expensive solution, go with CodeSmith or LLBLGen Pro. Good luck - anyone interested in using MyGeneration, feel free to contact me with questions.
NHibernate, but only if you would be amenable to having an object-first approach wherein you define your classes, and then define your desired table structure in the mapping files, and then create a database schema using NHibernate's built in schema generation classes.
For doing it the other way around (e.g., you have a bunch of tables and then you base your object design on that) I've found MyGeneration + NHibernate to work, although I'm not too happy with the resulting classes (mainly because I'm such a stickler for true Object Oriented Programming).
If I were in your shoes I would try to leverage what I knew (sprocs) with Linq2Sql. Linq2Sql can still use your sprocs but then you have the added bonus of putting a new tool in your belt. I think having a grasp on the Linq2XXX (X being a random technology not adult entertainment....which isn't a bad idea now that I think of it) syntax and methodology is going to be a great addition to your skill set using Linq over a collection of objects is way sweet.
But ultimately something like NHibernate will suit you better in the long run.
Use EntitySpaces. you will send me flowers, guaranteed. simply awesome. change the db as you like. hit the button, bang. all your changes are done. without changing your custom code. I love it.
How simple is the application? If I were to be working with schema/design stuff for a couple of months, and not really worry about an actual app . . . I would consider using EDM and a Dynamic Data Entities Web Application project. This get your going with the least amount of effort, in my opinion. This keeps you focused on schema, data and other groovey things. I hopefully don't get too many neg bumps from this one!
Here's how the new project dialog will look like this
You're already happy with stored procs and they might be enough to abstract away the changing schema. If ORMs aren't happy with stored procs then maybe they'd work with Views that you keep current on top of the changing schema.
If the database schema changes often, prefer the Entity Framework over LINQ2SQL. If the schema changes, using L2S you have to 1) Remove and re-add you table (loosing your customizations) 2) Modify the model by hand (as done here in stackoverflow)
The EF is a super-set of L2S, giving you more flexibility of usage and dbms-independence
Any solution can work, what you really need is a set of tests which will guarantee that basic operation like insert, select, update and delete works. This way you can simply run your tests and check if mappings are up-to-date.
发布评论
评论（12）
这里需要注意的一件关键事情是，如果数据库模式经常更改，您需要具有某种程度的编译时类型安全性。 我发现这是 NHibernate 的一个问题，因为它使用 xml 映射文件，因此如果您更改数据库模式中的某些内容，直到运行时您才知道映射已损坏。
这也是存储过程的问题。
使用 Linq2Sql 的优势在于，当您在编译时更改架构时，您可以准确地了解代码的具体问题所在。 对我来说，如果我正在使用经常更改的模式，那么这将优先于其他所有事情
One key thing to be aware of here is that if the database schema is changing frequently, you want to have some level of compile time type safety. I've found this to be a problem with NHibernate because it uses xml mapping files so if you change something in your database schema, you don't know until runtime that the mapping is broken.
It will also be a problem with stored procs.
Using Linq2Sql will give you the advantage of knowing where exactly your code is breaking when you change a schema at compile time. This for me, is something that would take precedence over everything else if I'm working with a frequently changing schema
我会使用构建提供程序（网站项目）设置来查看 SubSonic。 这非常有效，因为每次构建项目时它都会自动重新生成 DAL 对象，因此如果数据库的更改破坏了代码，则会出现构建错误。
它工作得很好，直到数据库模式变得非常复杂并且我们达到了 ActiveRecord 模式的限制，但只要模式不是非常复杂，它就工作得很好。 一旦架构稳定下来，您就可以进行切换，以便只在需要时构建 DAL。
I'd look at SubSonic with the build provider (Website Project) setup. That works great because it automatically regenerates the DAL objects every time you build your project, so if the database changes in a way that breaks your code, you get a build error.
It worked well until the database schema got really complex and we were hitting the limits of the ActiveRecord pattern, but as long as the schema's not hugely complex it works pretty well. Once the schema stabilizes, you can switch so that you're only building the DAL when you want to.
您肯定想使用 ORM。 任何 ORM 都可以，但您需要能够生成强类型类的东西。 当从表中添加、修改或删除字段时，您希望能够重新生成这些类，并仅处理修复编译时错误。 如果您使用动态模型，则可能会遇到许多令人讨厌的运行时错误。 这个非常重要！ 我是 sourceforge 上 MyGeneration 开发团队的一员，我认为这是解决您问题的一个很好的解决方案。 您可以生成 dOOdad、NHibernate、EasyObjects、EntitySpaces 等。如果您想使用更昂贵的解决方案，请使用 CodeSmith 或 LLBLGen Pro。 祝你好运 - 任何有兴趣使用 MyGeneration 的人，如有问题请随时与我联系。
You definitely want to use an ORM. Any ORM is ok, but you want something that will generate strongly typed classes. When fields get added, modified or deleted from a table, you want to be able to regenerate those classes, and deal with fixing compile time errors only. If you use a dynamic model, you're likely to have many nasty runtime errors. This is VERY important! I am part of the MyGeneration development team on sourceforge, and I think that is a great solution to your problem. You can generate dOOdads, NHibernate, EasyObjects, EntitySpaces, etc. If you want to go with a more expensive solution, go with CodeSmith or LLBLGen Pro. Good luck - anyone interested in using MyGeneration, feel free to contact me with questions.
NHibernate，但前提是您愿意采用对象优先的方法，在其中定义您的类，然后在映射文件中定义所需的表结构，然后使用 NHibernate 内置的模式生成类创建数据库模式。
为了以相反的方式做到这一点（例如，您有一堆表，然后您的对象设计基于它）我发现 MyGeneration + NHibernate 可以工作，尽管我对生成的类不太满意（主要是因为我是真正的面向对象编程的坚持者）。
NHibernate, but only if you would be amenable to having an object-first approach wherein you define your classes, and then define your desired table structure in the mapping files, and then create a database schema using NHibernate's built in schema generation classes.
For doing it the other way around (e.g., you have a bunch of tables and then you base your object design on that) I've found MyGeneration + NHibernate to work, although I'm not too happy with the resulting classes (mainly because I'm such a stickler for true Object Oriented Programming).
如果我处在你的位置，我会尝试利用我所知道的（存储过程）与 Linq2Sql。 Linq2Sql 仍然可以使用您的存储过程，但您还可以获得额外的好处，可以在您的腰带上添加一个新工具。 我认为掌握 Linq2XXX（X 是一种随机技术，而不是成人娱乐......现在我想起来这不是一个坏主意）语法和方法将是对您使用技能的一个很好的补充对对象集合的 Linq 非常好。
但从长远来看，像 NHibernate 这样的东西最终会更适合你。
If I were in your shoes I would try to leverage what I knew (sprocs) with Linq2Sql. Linq2Sql can still use your sprocs but then you have the added bonus of putting a new tool in your belt. I think having a grasp on the Linq2XXX (X being a random technology not adult entertainment....which isn't a bad idea now that I think of it) syntax and methodology is going to be a great addition to your skill set using Linq over a collection of objects is way sweet.
But ultimately something like NHibernate will suit you better in the long run.
EntitySpaces可以在一分钟内重新生成您的DAL/业务层，并且不会丢失代码，请参阅试用版==> 此处
无需注册，也可在 Visual Studio 下运行。
EntitySpaces can regenerate your DAL/Business Layer in one minute, and no code loss, see the trial version ==> HERE
No Registration Necessary, runs under Visual Studio as well.
使用实体空间。 你一定会送花给我，保证。
就是棒。 根据需要更改数据库。 按下按钮，砰。 您的所有更改均已完成。 无需更改您的自定义代码。 我喜欢它。
Use EntitySpaces. you will send me flowers, guaranteed.
simply awesome. change the db as you like. hit the button, bang. all your changes are done. without changing your custom code. I love it.
应用程序有多简单？ 如果我要处理模式/设计内容几个月，而不是真正担心实际的应用程序。 。 。 我会考虑使用 EDM 和动态数据实体 Web 应用程序项目。 在我看来，这可以让你以最少的努力完成任务。 这可以让你专注于模式、数据和其他棘手的事情。 我希望这不会给我带来太多负面影响！
新项目对话框如下所示 this< /a>
How simple is the application? If I were to be working with schema/design stuff for a couple of months, and not really worry about an actual app . . . I would consider using EDM and a Dynamic Data Entities Web Application project. This get your going with the least amount of effort, in my opinion. This keeps you focused on schema, data and other groovey things. I hopefully don't get too many neg bumps from this one!
Here's how the new project dialog will look like this
您已经对存储过程感到满意，它们可能足以抽象出不断变化的模式。 如果 ORM 对存储过程不满意，那么他们可能会使用您在不断变化的架构上保持最新的视图。
You're already happy with stored procs and they might be enough to abstract away the changing schema. If ORMs aren't happy with stored procs then maybe they'd work with Views that you keep current on top of the changing schema.
如果数据库架构经常更改，则优先选择实体框架而不是 LINQ2SQL。 如果架构发生变化，您必须使用 L2S
1) 删除并重新添加您的表格（丢失您的自定义设置）
2) 手动修改模型（如 stackoverflow 中所做的）
EF 是 L2S 的超集，为您提供更多的使用灵活性和 dbms 独立性
If the database schema changes often, prefer the Entity Framework over LINQ2SQL. If the schema changes, using L2S you have to
1) Remove and re-add you table (loosing your customizations)
2) Modify the model by hand (as done here in stackoverflow)
The EF is a super-set of L2S, giving you more flexibility of usage and dbms-independence
看看它为什么会发生变化，看看你是否可以预测并概括即将发生的变化类型，这样它们就不会破坏你的代码。
框架可能会让适应变化变得更容易，但更深入的分析将带来更长期的好处
look at why it is changing, and see if you can anticipate and generalize the kinds of changes coming at you so that they don't break your code
a framework may make accomodating the changes easier, but deeper analysis will have a longer-term benefit
任何解决方案都可以工作，您真正需要的是一组测试，以保证插入、选择、更新和删除等基本操作有效。 这样您就可以简单地运行测试并检查映射是否是最新的。
Any solution can work, what you really need is a set of tests which will guarantee that basic operation like insert, select, update and delete works. This way you can simply run your tests and check if mappings are up-to-date.