实体框架 - 对业务层需求的意见
目前我的网站有一个存储库模式，其中包含规范模式。我只需几行代码就可以从 .aspx 页面中获取数据，例如：
private IRepository repository;
protected void Page_Load(object sender, EventArgs e)
{
repository = new GenericRepository();
Specification<Book> specification = new Specification<Book>(b => b.Year == 1988);
lvBooks.DataSource = repository.GetAll<Book>(specification);
lvBooks.DataBind();
}
现在我的问题是，我的网站中是否需要业务层？如果您的答案是肯定的，为什么？ 目前看来，由于规范模式，我不需要页面和存储库之间的业务层。
谢谢你的意见。
At the moment my website has a repository pattern with the specification pattern in it. I can get data from within my .aspx page with just a few lines of code, example:
private IRepository repository;
protected void Page_Load(object sender, EventArgs e)
{
repository = new GenericRepository();
Specification<Book> specification = new Specification<Book>(b => b.Year == 1988);
lvBooks.DataSource = repository.GetAll<Book>(specification);
lvBooks.DataBind();
}
Now my question is, do I need a business layer in my website and if your answer is yes, why?
At the moment it seems, because of the specification pattern, that I have no need for a business layer who's between the page and the repository.
Thanks for your opinion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
答案取决于该应用程序有多大、将变得有多大以及可能发生多大的变化。
任何层的唯一真正意义是隔离功能。在小型应用程序中，您可以愉快地在整个 UI 代码中调用存储库。
但是，如果您随后更改存储库的结构方式会怎样？您需要查找并更改所有这些引用。
但是，如果您将所有存储库访问代码编写在向 UI 公开更高级别方法的业务层中，那么此时您要做的工作就会少得多。
可能存在特定的安全考虑。例如，如果您的 UI 无权访问存储库，那么您可以将所有安全检查集中在业务层的公共 API 上。如果您有一个 200 页的 Web 应用程序，可以从任何地方访问存储库 - 当然它可能是安全的 - 但您能确定吗？
然后是单元测试......基本上没有正确的方法 - 但如果你的应用程序很小，你没问题......如果你的应用程序很大，你可能会在某个时候后悔这个设计。
The answer is dependant on how big this application is, how big it's going to get, and how much it's likely to change.
The only real point of any layers is to isolate functionality. In a small application you can happily have calls to the repository sprinkled throughout the UI code.
But what if you then change something in the way the repository is structured? You'll need to find and change all those references.
However if you wrote all your repository access code in a business layer which exposes higher level methods to the UI then you've got much less work to do at this point.
There could be specific security considerations. For example if your UI doesn't have access to the repository then you can focus all your security checking on the public API of the business layer. If you have a 200 page web app where the repository can be accessed from anywhere - of course it could be secure - but how certain can you be?
Then there's unit testing...... basically there is no right way - but if your app is small you're fine... if your app is large you're probably going to regret this design at some point.
从您的代码看来您不需要业务层。因为它似乎都是关于使用简单规范或数据插入来获取数据。当您对这些对象有一些业务规则时，就需要 BL，例如：删除对象应在删除对象之前检查某些特定条件等
From your code it seems that you dont need business layer. As it seems its all about data fetching using simple specification or maybe data insertion. BL would be required when you have some business rules around these objects, ex: Deleting an object should check some specific condition before deleting the object etc