ASP.NET MVC - 删除 GUI 中 DAL 的依赖关系
我正在构建一个由 3 个项目组成的 MVC Web 应用程序。一种用于 GUI，一种用于业务逻辑，一种用于数据访问。
对于我的数据访问，我有一个由 EF 生成的文件，因此我有一个名为“Customer”的生成类。为了为这个类创建验证属性，我需要创建 MetaDataType （这需要在同一个命名空间中完成，因此我必须在 DAL 层中完成） - 通过这样做，我从 GUI 中引用数据访问层这破坏了拆分项目的整个想法，因为我的 GUI 现在同时引用了我的 DAL 和 BL 层。无论如何，我可以将 GUI 和 DAL 层分开，但仍然可以使用 [Required] 等验证属性吗？
提前致谢。
I'm building a MVC web app that consist of 3 projects. One for the GUI, one for the BusinessLogic and one for the Data access.
For my Data access I have a generated file by EF and therefore I have a generated class named "Customer". To make validation attributes for this class I need to make MetaDataType (which needs to be done in the same namespace and therefore I'm bound to do it in the DAL layer) - by doing this I refer to the Data access layer from my GUI which spoils the whole idea of splitting the project up, because that my GUI now refer both my DAL and BL layer. Is there anyhow I can keep my GUI and DAL layers seperated but still be abe to use Validation attributes like [Required] and so on?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您使用 .NET 4 (EF 2)，您可以在单独的类库中生成 POCO 实体，并可以在项目之间共享。这不需要依赖于 DAL。请参阅我之前的答案：
ASP.Net 分层应用程序 - 共享层间实体数据模型
特别是3. POCO模板，包括如何移动到单独的项目：http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-poco-templates-for-the-entity-framework .aspx
If you're using .NET 4 (EF 2) you can generate POCO entities in a separate class library that can be shared across projects. That won't require a dependency to the DAL. See my previous answer:
ASP.Net Layered app - Share Entity Data Model amongst layers
Especially 3. POCO templates, including how to move to separate project: http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-poco-templates-for-the-entity-framework.aspx
这就是 ViewModels 是关于。但这意味着您将拥有一组新的 DTO 用于视图控制器通信...恕我直言，这是一件好事，因为您的视图不应该了解有关真实域模型的任何信息。
关于使视图与模型进行通信的所有不同方式，请查看 这个。
That's what ViewModels are about. But that means you will have a new set of DTO's for the view-controller communication... Which is a good thing IMHO, since your views should not know anything about the real domain model.
Regarding all distinct ways of making your views communicate with the model, please take a look at this.