Questions about MVP design pattern and repository 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!

public class Company
    {
        [Required]
        [Key]
        public string CompanyCode { get; set; }
        public string CompanyName { get; set; }
        public CompanyTypes CompanyType { get; set; }
        public string CompanyTaxAdministration { get; set; }
        public string CompanyTaxNumber { get; set; }
        public string CompanyWebAdress { get; set; }
        public string CompanyMailAdress { get; set; }
        public byte[] CompanyLogo { get; set; }

        public virtual ICollection<CompanyAddress> CompanyAddresses { get; set; }

        public Company()
        {
            CompanyAddresses = new HashSet<CompanyAddress>();
        }
    }

public class Company
    {
        public string CompanyCode { get; set; }
        public string CompanyName { get; set; }
        public CompanyTypes CompanyType { get; et; }
        public string CompanyTaxAdministration { get; set; }
        public string CompanyTaxNumber { get; set; }
        public string CompanyWebAdress { get; set; }
        public string CompanyMailAdress { get; set; }
        public byte[] CompanyLogo { get; set; }

        public Company(string cCode, string cName, CompanyTypes cType, string taxAdmin, string cTaxNum, string web, string mail, byte[] logo)
        {
            CompanyCode = cCode;
            CompanyName = cName;
            CompanyType = cType;
            CompanyTaxAdministration = taxAdmin;
            CompanyTaxNumber = cTaxNum;
            CompanyWebAdress = web;
            CompanyMailAdress = mail;
            CompanyLogo = logo;
        }
    }