用于企业应用程序架构的 WPF、WCF 和实体框架

发布于 2024-11-27 11:29:27 字数 374 浏览 2 评论 0原文

我们正在努力将旧项目改为新技术。我们决定使用 EF + WCF + WPF 和 SOA 方法。

经过一番研究,我们决定使用以下架构:

  • EF 用于数据库操作 (CRUD) - 在服务器上
  • DTO 用于数据传输(这里我们有 2 个映射:DTO-EF 和 EF-DTO)。
  • 业务对象将位于客户端 - 实现 WPF 接口的类(IEditableObject、INotifyPropertyChanged 等)(这里我们再次放置两个映射转换 - DTO-BO 和 BO-DTO)
  • 验证将一部分在客户端,一部分在服务器上。

有人可以告诉我这对于平均规模的企业应用程序来说是否是正确的方法,如果不是的话,哪里出了问题。

We are working on changing an old project to a new technology. We decided to use EF + WCF + WPF with a SOA aproach.

After some research we decided to use the following architecture:

  • EF for the database operations (CRUD) - on the server
  • DTO for data transport (here we have 2 mappings: DTO-EF & EF-DTO).
  • the business objects will be on the client - classes implementing the WPF interfaces(IEditableObject, INotifyPropertyChanged, etc) (here we put again two mapping transforms - DTO-BO & BO-DTO)
  • the validation will be part on the client side, part on the server.

Can someone tell me if this is a correct aproach for a average size enterprise app and if not what is wrong.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

很快妥协 2024-12-04 11:29:27

两点评论:

  • 同时拥有 DTO 和 BO 似乎没有必要,您可以让 DTO 实现 INotifyPropertyChanged 并省去中间人。您还将在这些之上创建 ViewModel 类,它很快就会变得非常难以管理。它还容易出现映射错误。

    同时

  • 您没有提到使用任何映射库进行 DTO<->EF 复制。考虑使用 AutoMapper 或 ValueInjecter。

Two comments:

  • Having both DTO and BO seems unnecessary, you can make DTOs to implement INotifyPropertyChanged and cut out the middle man. You will also create ViewModel classes on top of these, it will become quite unmanageable soon. It is also prone for mapping errors.

  • You haven't mentioned about using any mapping libraries for DTO<->EF copy. Consider using AutoMapper or ValueInjecter.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文