关于MVP设计模式和存储库设计模式的问题 [英] Questions about MVP design pattern and repository design pattern
问题描述
嗨;
我需要更改已经开发的桌面应用程序。（使用winforms开发的应用程序）
应用程序已经设计了具有单独UserControls（例如PriceOfferRequestUserControl，OrderUserControl等），数据库表和模型的UI。我想要做的是实现一个设计模式，以增加应用程序的维护性。
之前我没有使用MVP设计模式，但我使用了存储库设计模式对于Web服务项目。
我的问题是：
- MVP设计模式是否适合企业桌面应用程序？如果不是最适合企业桌面应用程序的设计模式？
- 我可以将MVP设计模式与存储库设计模式一起使用吗？如果我不能与数据库进行通信的最佳方式是什么？
- 正如我之前提到的，应用程序已经创建了模型（对象）。但是如果我使用存储库模式，EntityFramework也会从数据库中创建模型。在这种情况下，我应该使用哪种型号，现有的或已创建的型号？
谢谢。
我的尝试：
我看了一些MVP设计模式的例子。
好的宣言在这里!!!
将MVP实施到现有的1层应用程序应用程序是一个重写。除非你没有积压，并且应用程序有很多测试人员，否则我不建议这样做。否则，擦亮你的简历，除非你的老板期待重写和所有延迟和重新测试。
在这种情况下，完全使用现代平台。除非你有Win7或更低的用户 - 使用Xamarin表格，它的桌面/ win10兼容，并可以去移动。使用MVVM。当然，这是一个完全不同的发展理念。
如果是win7，请使用WPF，但那里没有移动路线。
但是MVP也是如此只有MVP，你才能手动完成所有事情。 MVVM很多都是微软内置的。
支持MVP：你可能会保留稍微多一点的winforms相关代码，但几乎所有代码都必须是卡在视图中，这会削弱升级的好处。当然，如果时间用完，它也会给你一个出局 - 至少有些会被重构/重写。
我的建议：找到新的需求您的用户，使用现代架构启动新应用程序。如果没有，请进行重构/重写。
关于存储库模式：它是一个强大的工具。请注意不要将存储库注入域对象。这些应该在更高级别连接 - 调用域对象的对象。这是演示者（或视图模型）与域模型之间的层。域对象不应该知道存储库，他们不应该知道保存/加载自己。它们不应该直接引用其他域对象。
当然，存储库会知道你的域对象，你必须注入它，映射将在其中。
这会将一些代码移动到该层（DDD称之为'服务'代码层，其他人称之为应用层，许多人不知道它的用处）。注意：让域对象知道存储库的抽象是一样糟糕的耦合。
每个人都制作对象，这样你就可以做到'foreach（客户账号）。账户）......'......然后把这个逻辑放在客户身上。那不是SoC。它跨越两个业务对象。不要将引用或引用列表放在另一个业务对象中。把那个触及ddd-services层的逻辑放在一起。 （注意这些不是业务对象 - 它们引用业务对象）这也解决了n + 1问题。这也解决了95％的物体 - 关系阻抗不匹配问题。这使您可以在应用程序中执行所需操作并坚持使用SQL而无需吃NoSql的干麸皮片。很多事情都到位了。
通过PK ID和FK ID将业务对象拼接在一起。有些人会声称这会将SQL实现泄漏到对象中。但是，如果你在SQL中存储，你别无选择。它并没有带来那些泄漏的缺点。如果你把它们放在你的对象的字符串类型中，那么它可以保存int，guid，复合键等，无论你可以改变它。换句话说，不要担心这种泄漏。
当然不要走得太远或者你的业务对象会变得贫血。对于简单的情况，只要您不保留对其他业务对象的引用，参数注入就可以了。示例（ddd-services层对象中的代码 - 其他注入 - cust.GetAmountDue（来自帐户中的acct.custid == cust.id））。在这里，您将一个可枚举的Account-by参数注入到Customer的GetAmountDue方法中。没有构造函数/属性注入 - 这是持有引用！
对于第3个问题，如果您使用EF跳过存储库，或者您将对数据库进行双重包装。 AFAIK大多数ORM都内置了用于单元测试的模拟。知道Business Objects不应该自行保留有助于理解这一点。在DDD服务层中，将EF模型映射到域对象。为了世界上所有的好处，使用AutoMapper（etc）或ExpandoObjects / Propertybag域对象，使用匹配的属性名称（通过它们循环映射），否则，准备好结束它所有寻找错误你将让猴子编码的东西。
如果这太多了，请记住 - SOLID不做或死。它只能比一个写得很好的OO程序好20-30％，从一个幻想的角度看起来相当保守，直到你擅长它，很可能会让事情比这更糟糕20-50％！
Hi;
I need to change an already developed desktop application.(Application developed by using winforms)
The application have already designed UI's with seperate UserControls(ex. PriceOfferRequestUserControl, OrderUserControl etc.), database tables and models. What I want to do is implementing a design pattern(s) for increase the application's maintability.
I haven't used MVP design pattern before but I used repository desing pattern for web service project.
My questions are;
- Is MVP design pattern suitible for enterprise desktop application? If it isn't what desing patterns best suited for enterprise desktop applications?
- Can I use MVP design pattern with repository design pattern? If I can't what is the best way to communicate with database?
- As I mentioned before, application have already creadted models(objects). But if I use the repository pattern EntityFramework also creates models from database. In this situation which model's should I use, existing ones or the created ones?
Thank you.
What I have tried:
I looked some examples for MVP design pattern.
OK manifesto here!!!
Implementing MVP into an existing 1-layer app app is a rewrite. I wouldn't recommend that unless you have no backlog, and lots of testers for the app. Otherwise, polish off your resume, unless your boss is expecting a re-write and all the delays and retesting that go with it.
In that case, use a completely modern platform. Unless you have Win7 or lower users - use Xamarin forms, it's desktop/win10 compatible, and can go to mobile. Use MVVM. Of course, it's a completely different development philosophy.
If win7, use WPF, but there's no mobile route there.
But so is MVP, only with MVP you will do everything manually. MVVM a lot is built-in many ways by Microsoft.
In favor of MVP: you might keep slightly more winforms related code, but, almost all would have to be stuck in the views, which would weaken the benefit of an upgrade. Of course, it would also give you an 'out' if time ran out - at least some would be refactored/rewritten.
My recommendation: find a new need of your users, start the new app using modern architecture. If none, do the refactor/re-write.
Regarding the repository pattern: it's a powerful tool. Take note not to inject repositories into your domain objects. These should be wired up at a higher level - the objects that call the domain objects. This is a layer between the Presenters (or viewmodels) and the domain model. Domain objects shouldn't know about repositories, they shouldn't know to save/load themselves. They shouldn't have direct references to other domain objects.
Of course, repositories will know about your domain objects, you have to inject it, the mapping will be in them.
This moves some code into that layer (DDD calls it 'services' code layer, others call it the application layer, many don't know of its usefulness). Note: having the domain objects know about abstractions of the repositories is just as bad coupling wise.
Everybody makes objects so you can do 'foreach (Account acct in Customer.Accounts)...' ... and then put that logic in customer. That's not SoC. It spans both business objects. Don't put references or list of references to one business object in another. Put that logic that touches both in the ddd-services layer. (note these are not business objects - they take references to the business objects) This also solves the n+1 problem. this also solves 95% of the Objects-Relational impedance mismatch. This lets you do what you want in your app and persist to SQL without eating the dry bran flakes of NoSql. A lot of things fall in place.
Stitch business objects together by their PK IDs an FK ids. Some will claim this leaks the SQL implementation into the objects. But if you're storing in SQL anyway you have no choice. And it doesn't carry the disadvantage of those leaks esp. if you put them in string types in your objects, then it can hold int, guid, composite key, etc. whatever you can change it to. In other words, don't worry about such 'leaking'.
Don't go too far of course or your business objects will be anemic. For simple cases parameter injection is OK as long as you don't keep a reference to the other business object. Example (code in ddd-services layer object - which gets the others injected - cust.GetAmountDue(from acct in accounts where acct.custid==cust.id) ). Here you injected an enumerable of Account - by parameter - into the GetAmountDue method of Customer. No constructor/property injection - that's holding the reference!
For your 3rd question, if you use EF skip the repositories or you will be double-wrapping your DB. AFAIK most ORMs have mocking built in for your unit tests. Knowing that Business Objects should not persist themselves helps this make sense. In your DDD-services layer map the EF models to your domain objects. For the sake of all that is good in the world, use AutoMapper (etc), or ExpandoObjects/Propertybag domain objects, with matching property names (loop thru them to map), otherwise, get ready to end it all looking for errors you will make monkey-coding the stuff.
If this is all too much, remember - SOLID is not do or die. It can only make things 20-30% better than a well-written OO program that took a reasonably conservative to from a fanciness standpoint, and until you get good at it, chances are it will make things 20-50% WORSE than that!
这篇关于关于MVP设计模式和存储库设计模式的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
