手动 DAL 和 BLL 与 ORM
哪种方法更好：1)使用第三方 ORM系统或2)手动编写 DAL 和 BLL 代码 strong> 使用数据库？
1) 在我们的一个项目中，我们决定使用 DevExpress XPO ORM 系统，但我们遇到了很多小问题，浪费了我们很多时间。 AMD仍然时不时地遇到来自这个ORM的问题和异常，而我们对这个“黑匣子”并没有完全的理解和控制。
2) 在另一个项目中，我们决定从头开始编写 DAL 和 BLL。 虽然这意味着要多次编写无聊的代码，但事实证明这种方法更加通用和灵活：我们可以完全控制数据在数据库中保存的方式、如何从中获取数据等。并且所有错误都可以以直接且简单的方式进行修复。
哪种方法通常更好？ 也许问题只是出在我们使用的 ORM (DevExpress XPO) 上，也许其他 ORM 更好（例如 NHibernate）？
是否值得使用ADO Entiry Framework？
我发现DotNetNuke CMS 使用自己的DAL 和BLL 代码。 其他项目呢？
我想了解您的个人经历：您在项目中使用哪种方法，哪种方法更可取？
谢谢。
Which approach is better: 1) to use a third-party ORM system or 2) manually write DAL and BLL code to work with the database?
1) In one of our projects, we decided using the DevExpress XPO ORM system, and we ran across lots of slight problems that wasted a lot of our time. Amd still from time to time we encounter problems and exceptions that come from this ORM, and we do not have full understanding and control of this "black box".
2) In another project, we decided to write the DAL and BLL from scratch. Although this implied writing boring code many, many times, but this approach proved to be more versatile and flexible: we had full control over the way data was held in the database, how it was obtained from it, etc. And all the bugs could be fixed in a direct and easy way.
Which approach is generally better? Maybe the problem is just with the ORM that we used (DevExpress XPO), and maybe other ORMs are better (such as NHibernate)?
Is it worth using ADO Entiry Framework?
I found that the DotNetNuke CMS uses its own DAL and BLL code. What about other projects?
I would like to get info on your personal experience: which approach do you use in your projects, which is preferable?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我个人的经验是 ORM 通常完全是浪费时间。
首先，考虑一下这背后的历史。 早在 60 年代和 70 年代初，我们就有了使用分层和网络模型的 DBMS。 这些使用起来有点痛苦，因为在查询它们时，您必须处理所有检索机制：跟踪各地记录之间的链接，并处理链接不是您想要的链接时的情况（例如，对于您的特定查询指向错误的方向）。 因此，Codd 提出了关系 DBMS 的想法：指定事物之间的关系，在查询中只说出您想要的内容，然后让 DBMS 处理检索它的机制。 一旦我们对此有了一些好的实现，数据库人员就欣喜若狂，每个人都转向它，整个世界都很高兴。
直到面向对象的人们进入商业世界。
面向对象的人员发现了这种阻抗不匹配：业务编程中使用的 DBMS 是关系型的，但在内部，面向对象的人员通过链接（引用）存储内容，并通过弄清楚他们必须遵循的链接的详细信息并跟踪它们来找到内容。 是的：这本质上是分层或网络 DBMS 模型。 因此，他们投入了大量（通常是巧妙的）努力，将层次/网络模型分层回关系数据库，顺便抛弃了 RDBMS 给我们带来的许多优势。
我的建议是学习关系模型，在合适的情况下围绕它设计系统（通常是这样），并利用 RDBMS 的强大功能。 您将避免阻抗不匹配，您通常会发现查询很容易编写，并且您将避免性能问题（例如您的 ORM 层需要数百个查询来完成它应该在一个查询中完成的事情）。
在处理查询结果时需要完成一定量的“映射”，但是如果您以正确的方式思考的话，这会很容易：结果关系的标题映射到一个类，并且关系中的每个元组都是一个对象。 根据您需要的进一步逻辑，可能值得也可能不值得为此定义一个实际的类； 只需处理从结果生成的哈希列表就足够容易了。 只需浏览并处理该列表，做您需要做的事情，就完成了。
My personal experience has been that ORM is usually a complete waste of time.
First, consider the history behind this. Back in the 60s and early 70s, we had these DBMSes using the hierarchical and network models. These were a bit of a pain to use, since when querying them you had to deal with all of the mechanics of retrieval: follow links between records all over the place and deal with the situation when the links weren't the links you wanted (e.g., were pointing in the wrong direction for your particular query). So Codd thought up the idea of a relational DBMS: specify the relationships between things, say in your query only what you want, and let the DBMS deal with figuring out the mechanics of retrieving it. Once we had a couple of good implementations of this, the database guys were overjoyed, everybody switched to it, and the world was happy.
Until the OO guys came along into the business world.
The OO guys found this impedance mismatch: the DBMSes used in business programming were relational, but internally the OO guys stored things with links (references), and found things by figuring out the details of which links they had to follow and following them. Yup: this is essentially the hierarchical or network DBMS model. So they put a lot of (often ingenious) effort into layering that hierarchical/network model back on to relational databases, incidently throwing out many of the advantages given to us by RDBMSes.
My advice is to learn the relational model, design your system around it if it's suitable (it very frequently is), and use the power of your RDBMS. You'll avoid the impedance mismatch, you'll generally find the queries easy to write, and you'll avoid performance problems (such as your ORM layer taking hundreds of queries to do what it ought to be doing in one).
There is a certain amount of "mapping" to be done when it comes to processing the results of a query, but this goes pretty easily if you think about it in the right way: the heading of the result relation maps to a class, and each tuple in the relation is an object. Depending on what further logic you need, it may or may not be worth defining an actual class for this; it may be easy enough just to work through a list of hashes generated from the result. Just go through and process the list, doing what you need to do, and you're done.
也许两者兼而有之才是正确的选择。 您可以使用 SubSonic 这样的产品。 这样，您可以设计数据库，生成 DAL 代码（删除所有那些无聊的东西），使用部分类用您自己的代码扩展它，如果您愿意，可以使用存储过程，并且通常可以完成更多工作。
我就是做这个的。 我发现这是自动化和控制之间的正确平衡。
我还想指出，我认为通过尝试不同的方法并看看什么最适合您，您走在正确的道路上。您。 我认为这最终是您答案的来源。
Perhaps a little of both is the right fit. You could use a product like SubSonic. That way, you can design your database, generate your DAL code (removing all that boring stuff), use partial classes to extend it with your own code, use Stored Procedures if you want to, and generally get more stuff done.
That's what I do. I find it's the right balance between automation and control.
I'd also point out that I think you're on the right path by trying out different approaches and seeing what works best for you. I think that's ultimately the source for your answer.
最近我决定在一个新项目中使用 Linq to SQL，我真的很喜欢它。 它是轻量级的、高性能的、直观的，并且有许多微软（和其他公司）的专家在博客上介绍它。
Linq to SQL 的工作原理是从数据库创建 C# 对象的数据层。 DevExpress XPO 的工作方向相反，为 C# 业务对象创建表。 实体框架应该以任何一种方式工作。 我是一名数据库专家，因此为我设计数据库的框架的想法没有多大意义，尽管我可以看到它的吸引力。
我的 Linq to SQL 项目是一个中型项目（数百甚至数千用户）。 对于较小的项目，有时我只使用 SQLCommand 和 SQLConnection 对象，并直接与数据库对话，效果很好。 我还使用 SQLDataSource 对象作为我的 CRUD 的容器，但这些看起来很笨重。
您的项目越大，DAL 就越有意义。 如果它是一个 Web 应用程序，我总是使用某种 DAL，因为它们具有内置的保护措施，可以防止 SQL 注入攻击、更好地处理空值等。
我争论是否为我的项目使用实体框架，因为 Microsoft表示这将是他们未来数据访问的首选解决方案。 但 EF 对我来说还不够成熟，如果你在 StackOverflow 上搜索 Entity Framework，你会发现很多人都在为一些小而迟钝的问题而苦苦挣扎。 我怀疑版本 2 会好得多。
我对 nHibernate 一无所知，但有人喜欢它并且不会使用其他任何东西。
Recently I made the decision to use Linq to SQL on a new project, and I really like it. It is lightweight, high-performance, intuitive, and has many gurus at microsoft (and others) that blog about it.
Linq to SQL works by creating a data layer of c# objects from your database. DevExpress XPO works in the opposite direction, creating tables for your C# business objects. The Entity Framework is supposed to work either way. I am a database guy, so the idea of a framework designing the database for me doesn't make much sense, although I can see the attractiveness of that.
My Linq to SQL project is a medium-sized project (hundreds, maybe thousands of users). For smaller projects sometimes I just use SQLCommand and SQLConnection objects, and talk directly to the database, with good results. I have also used SQLDataSource objects as containers for my CRUD, but these seem clunky.
DALs make more sense the larger your project is. If it is a web application, I always use some sort of DAL because they have built-in protections against things like SQL injection attacks, better handling of null values, etc.
I debated whether to use the Entity Framework for my project, since Microsoft says this will be their go-to solution for data access in the future. But EF feels immature to me, and if you search StackOverflow for Entity Framework, you will find several people who are struggling with small, obtuse problems. I suspect version 2 will be much better.
I don't know anything about nHibernate, but there are people out there who love it and would not use anything else.
您可以尝试使用 NHibernate。 由于它是开源的，因此它并不完全是一个黑匣子。 它非常通用，并且有许多扩展点供您插入自己的附加或替换功能。
评论 1：
NHibernate 是一个真正的 ORM，因为它允许您在任意域模型（类）和任意数据模型（表、视图、函数和过程）之间创建映射。 您告诉它您希望如何将类映射到表，例如，该类是否映射到两个连接的表或两个类映射到同一个表，该类属性是否映射到多对多关系等。 NHibernate 希望您的数据模型大部分标准化，但它不要求您的数据模型与您的领域模型精确对应，也不会生成您的数据模型。
评论2：
NHibernate的方法是允许你编写任何你喜欢的类，然后告诉NHibernate如何将这些类映射到表。 没有可以继承的特殊基类，没有所有一对多属性都必须的特殊列表类，等等。NHibernate 无需它们也能发挥其魔力。 事实上，您的业务对象类根本不应该对 NHibernate 有任何依赖。 您的业务对象类本身绝对没有持久性或数据库代码。
您很可能会发现您可以对 NHibernate 使用的数据访问策略进行非常细粒度的控制，以至于 NHibernate 也可能是您复杂情况的绝佳选择。 然而，在任何给定的上下文中，您都可以根据需要自由地使用 NHibernate 或不使用它（支持更自定义的 DAL 代码），因为当您不需要它时，NHibernate 会尽量不妨碍您。 因此，您可以在一个 BLL 类（或方法）中使用自定义 DAL 或 DevExpress XPO，并且可以在另一个 BLL 类（或方法）中使用 NHibernate。
You might try using NHibernate. Since it's open source, it's not exactly a black box. It is very versatile, and it has many extensibility points for you to plug in your own additional or replacement functionality.
Comment 1:
NHibernate is a true ORM, in that it permits you to create a mapping between your arbitrary domain model (classes) and your arbitrary data model (tables, views, functions, and procedures). You tell it how you want your classes to be mapped to tables, for example, whether this class maps to two joined tables or two classes map to the same table, whether this class property maps to a many-to-many relation, etc. NHibernate expects your data model to be mostly normalized, but it does not require that your data model correspond precisely to your domain model, nor does it generate your data model.
Comment 2:
NHibernate's approach is to permit you to write any classes you like, and then after that to tell NHibernate how to map those classes to tables. There's no special base class to inherit from, no special list class that all your one-to-many properties have to be, etc. NHibernate can do its magic without them. In fact, your business object classes are not supposed to have any dependencies on NHibernate at all. Your business object classes, by themselves, have absolutely no persistence or database code in them.
You will most likely find that you can exercise very fine-grained control over the data-access strategies that NHibernate uses, so much so that NHibernate is likely to be an excellent choice for your complex cases as well. However, in any given context, you are free to use NHibernate or not to use it (in favor of more customized DAL code), as you like, because NHibernate tries not to get in your way when you don't need it. So you can use a custom DAL or DevExpress XPO in one BLL class (or method), and you can use NHibernate in another.
我最近参加了一个足够大的有趣项目。 我从一开始就没有加入它，我们必须支持已经实现的架构。 对所有对象的数据访问是通过存储过程和在 .NET 上自动生成的返回 DataTable 对象的包装方法来实现的。 这种系统的开发过程非常缓慢且低效。 我们必须在 PL/SQL 上为每个查询编写巨大的存储过程，这可以用简单的 LINQ 查询来表达。 如果我们使用 ORM，我们的项目实施速度会快好几倍。 我没有看到这种架构有任何优势。
我承认，这只是一个不太成功的项目，但我得出了以下结论：在拒绝使用 ORM 之前请三思，你真的需要这样的灵活性和对数据库的控制吗？ 我认为在大多数情况下，不值得浪费时间和金钱。
I recently took part in sufficiently large interesting project. I didn't join it from the beginning and we had to support already implemented architecture. Data access to all objects was implemented through stored procedures and automatically generated wrapper-methods on .NET that returned DataTable objects. The development process in such system was really slow and inefficient. We had to write huge stored procedure on PL/SQL for every query, that could be expressed in simple LINQ query. If we had used ORM, we would have implement project several times faster. And I don't see any advantage of such architecture.
I admit, that it is just particular not very successful project, but I made following conclusion: Before refusing to use ORM think twice, do you really need such flexibility and control over database? I think in most cases it isn't worth wasted time and money.
正如其他人所解释的那样，ORM 存在一个根本性的困难，这使得现有的解决方案在大多数情况下都无法很好地做正确的事情。 此博客文章：计算机科学的越南< /a> 呼应了我对此的一些感受。
执行摘要是沿着对象模型和关系模型之间不兼容的假设和优化的内容。 尽管早期回报不错，但随着项目的进展，ORM 的抽象性会出现不足，并且围绕它进行工作的额外开销往往会抵消成功的成果。
As others explain, there is a fundamental difficulty with ORM's that make it such that no existing solution does a very good job of doing the right thing, most of the time. This Blog Post: The Vietnam Of Computer Science echoes some of my feelings about it.
The executive summary is something along the lines of the assumptions and optimizations that are incompatible between object and relational models. although early returns are good, as the project progresses, the abstractions of the ORM fall short, and the extra overhead of working around it tends to cancel out the successes.
我已经使用Bold for Delphi四年了。 它很棒，但不再出售，并且缺少一些功能，例如数据绑定。 ECO 继任者拥有这一切。
不，我不是在销售 ECO 许可证或其他东西，但我只是觉得遗憾的是很少有人意识到 MDD（模型驱动开发）可以做什么。 能够在更短的时间内解决更复杂的问题并减少错误。 这很难衡量，但我听说过开发效率提高了 5-10 倍。 当我每天使用它时，我知道这是真的。
也许一些以数据和 SQL 为中心的传统开发人员会说：
好吧...
如果您想尽快加载表的 10000 个实例，那么使用存储过程可能会更好，但大多数应用程序不这样做。 Bold 和 ECO 都使用简单的 SQL 查询来加载数据。 性能高度依赖于加载一定量数据时对数据库的查询数量。 开发人员可以通过说这些数据属于彼此来提供帮助。 尽可能高效地加载它们。
当然可以记录执行的实际查询以捕获任何性能问题。 如果您确实想使用超级优化的 SQL 查询，只要它不更新数据库就没有问题。
有很多 ORM 系统可供选择，特别是如果您使用 dot.net。 但说实话，做一个好的 ORM 框架是非常非常难的。 它应该集中在模型周围。 如果模型发生变化，更改数据库和依赖于模型的代码应该是一件容易的任务。 这使得维护变得容易。 进行小而多的改变的成本非常低。 许多开发人员都会犯这样的错误：以数据库为中心并围绕数据库调整一切。 在我看来，这不是最好的工作方式。
更多的人应该尝试ECO。 只要模型不超过12类，就可以无限次免费使用。 12 节课你可以做很多事！
I have used Bold for Delphi four years now. It is great but it is not available anymore for sale and it lacks some features like databinding. ECO the successor has all that.
No I'm not selling ECO-licenses or something but I just think it is a pity that so few people realize what MDD (Model Driven Development) can do. Ability to solve more complex problems in less time and fewer bugs. This is very hard to measure but I have heard something like 5-10 more efficient development. And as I work with it every day I know this is true.
Maybe some traditional developer that is centered around data and SQL say:
Well...
If you want to load 10000 instances of a table as fast as possible it may be better to use stored procedures, but most application don't do this. Both Bold and ECO use simple SQL queries to load data. Performance is highly dependent of the number of queries to the database to load a certain amount of data. Developer can help by saying this data belong to each other. Load them as effiecent as possible.
The actual queries that is executed can of course be logged to catch any performance problems. And if you really want to use your hyper optimized SQL query this is no problem as long as it don't update the database.
There is many ORM system to choose from, specially if you use dot.net. But honestly it is very very hard to do a good ORM framework. It should be concentrated around the model. If the model change, it should be an easy task to change database and the code dependent of the model. This make it easy to maintain. The cost for making small but many changes is very low. Many developers do the mistake to center around the database and adapt everthing around that. In my opinion this is not the best way to work.
More should try ECO. It is free to use an unlimited time as long the model is no more than 12 classes. You can do a lot with 12 classes!
我建议您使用 Code Smith Tool 来创建 Nettiers，这对于开发人员来说是一个不错的选择。
I suggest you to use Code Smith Tool for creating Nettiers, that is a good option for developer.