There are several undeniable truths in software development:
A prototype becomes a product before you know it.
An app targetted "just for platform-x" will soon be ported to platform-y.
The data-store will change. Probably as a result of #2.
There are more ( :) ) but these are enough for to answer your question:
Go with a respository so your objects can be tested, know nothing about persistence, and you can swap out data stores (even go over the wire!) Might as well plan for that up-front.
从好的方面来说，这是一种更容易让人掌握的模式，并且是在轻量级项目上完成工作的快速方法。如果类的数量很小，这可能是从 A 到 B 的最快方法。但是，我仍然发现自己在小型项目上构建单独的存储库，我只是无法忍受将持久性内容与我的业务逻辑混合在一起。
Sounds like you're talking about the Active Record pattern? It works for some folks but there are criticisms against it (mostly from a testability / separation of concerns standpoint).
The biggest issue is that you end up with persistence logic spread out across all your classes. That can quickly lead to bloat, and it also embeds assumptions about your persistence technology all over your codebase. That gets messy if you need to change where or how you store your objects.
Those assumptions also make automated testing more difficult because now you have a persistence layer dependency to work around. You could inject a repository into the object to counteract some of this stuff, but then you're implementing a repository anyway. :) Better to just keep the core classes entirely peristence-ignorant if you can...
On the plus side, it's a simpler pattern for people to grasp and is a quick way to get things done on a lightweight project. If the number of classes is small it could be the quickest way to get from A to B. I still find myself building out separate repositories on small projects however, I just can't stand having persistence stuff mixed in with my business logic.
基本上，如果您的数据模型是扁平且简单的，如果您的应用程序要求不高，Active Record 可能是一个不错的选择；然而，当您的映射要求变得更加复杂时，它就会开始崩溃。更强大的 ORM 模式（例如 Data Mapper）适合此类情况。
Cons:
Violates Single Responsibility Principle (SRP)
Hampers testability
Tightly couples you business logic to your database
Pros:
Is simple to implement
Basically, if your data model is flat and simple, and your application requirements are modest, Active Record might be a good choice; however, it starts to break down when your mapping requirements get a bit more complex. More robust ORM patterns like Data Mapper become appropriate in cases like these.
如果它是一个简单的应用程序，您可能可以放弃 DAL 层，并采用更简单的模型。尽管如果您的应用程序有很多移动部件并且相当复杂，我会避免删除 DAL，因为您希望能够很好地测试和验证您的代码。
Pros
simplicity
Cons
breaks separation of concerns
tight coupling of business logic with database
makes testing much more difficult
This pretty much boils down to testing becoming much harder, and decreasing the time before you have to do a major refactor in your project.
At the end of the day you need to weigh your goals and concerns for the project and decide if the loss of testing/verifiability/cleaness is worth it to gain a simpler system.
If it's a simple application, you're probably fine to drop the DAL layer, and go for the simpler model. Though if you application has lots of moving parts and is of considerable complexity, I would avoid removing the DAL as you will want to be able to test and verify your code well.
发布评论
评论（5）
软件开发中有几个不可否认的事实：
还有更多（:)），但这些足以回答您的问题：
使用存储库，以便可以测试您的对象，对持久性一无所知，并且您可以交换数据存储（甚至通过网络！）预先做好计划。
There are several undeniable truths in software development:
There are more ( :) ) but these are enough for to answer your question:
Go with a respository so your objects can be tested, know nothing about persistence, and you can swap out data stores (even go over the wire!) Might as well plan for that up-front.
听起来您好像在谈论 Active Record 模式？它对某些人有用，但也有人批评它（主要是从可测试性/关注点分离的角度来看）。
最大的问题是，持久性逻辑最终会分布在所有类中。这会很快导致膨胀，并且还会在代码库中嵌入关于持久性技术的假设。如果您需要更改存储对象的位置或方式，那就会变得混乱。
这些假设也使自动化测试变得更加困难，因为现在您需要解决持久层依赖项。您可以将存储库注入到对象中以抵消其中的一些内容，但无论如何您都会实现存储库。 :) 如果可以的话，最好让核心类完全不持久化......
从好的方面来说，这是一种更容易让人掌握的模式，并且是在轻量级项目上完成工作的快速方法。如果类的数量很小，这可能是从 A 到 B 的最快方法。但是，我仍然发现自己在小型项目上构建单独的存储库，我只是无法忍受将持久性内容与我的业务逻辑混合在一起。
Sounds like you're talking about the Active Record pattern? It works for some folks but there are criticisms against it (mostly from a testability / separation of concerns standpoint).
The biggest issue is that you end up with persistence logic spread out across all your classes. That can quickly lead to bloat, and it also embeds assumptions about your persistence technology all over your codebase. That gets messy if you need to change where or how you store your objects.
Those assumptions also make automated testing more difficult because now you have a persistence layer dependency to work around. You could inject a repository into the object to counteract some of this stuff, but then you're implementing a repository anyway. :) Better to just keep the core classes entirely peristence-ignorant if you can...
On the plus side, it's a simpler pattern for people to grasp and is a quick way to get things done on a lightweight project. If the number of classes is small it could be the quickest way to get from A to B. I still find myself building out separate repositories on small projects however, I just can't stand having persistence stuff mixed in with my business logic.
缺点：
优点：
基本上，如果您的数据模型是扁平且简单的，如果您的应用程序要求不高，Active Record 可能是一个不错的选择；然而，当您的映射要求变得更加复杂时，它就会开始崩溃。更强大的 ORM 模式（例如 Data Mapper）适合此类情况。
Cons:
Pros:
Basically, if your data model is flat and simple, and your application requirements are modest, Active Record might be a good choice; however, it starts to break down when your mapping requirements get a bit more complex. More robust ORM patterns like Data Mapper become appropriate in cases like these.
优点
缺点
这几乎可以归结为测试变得更加困难，并减少了在项目中进行重大重构之前的时间。
最终，您需要权衡项目的目标和关注点，并决定为了获得更简单的系统而牺牲测试/可验证性/清洁性是否值得。
如果它是一个简单的应用程序，您可能可以放弃 DAL 层，并采用更简单的模型。尽管如果您的应用程序有很多移动部件并且相当复杂，我会避免删除 DAL，因为您希望能够很好地测试和验证您的代码。
Pros
Cons
This pretty much boils down to testing becoming much harder, and decreasing the time before you have to do a major refactor in your project.
At the end of the day you need to weigh your goals and concerns for the project and decide if the loss of testing/verifiability/cleaness is worth it to gain a simpler system.
If it's a simple application, you're probably fine to drop the DAL layer, and go for the simpler model. Though if you application has lots of moving parts and is of considerable complexity, I would avoid removing the DAL as you will want to be able to test and verify your code well.
它与使用数据访问层背道而驰……并不是说这有什么问题。
It flies in the face of using a Data Access Layer...not that there's anything wrong with that.