Рейтинг:
11
fastal
Ладно, манифест здесь!!!
Реализация MVP в существующем 1-слойном приложении app-это перезапись. Я бы не рекомендовал этого делать, если только у вас нет бэклога и большого количества тестеров для приложения. В противном случае отполируйте свое резюме, если только ваш босс не ожидает переписывания и всех задержек и повторных тестов, которые с ним связаны.
В таком случае используйте совершенно современную платформу. Если у вас нет Win7 или более низких пользователей - используйте Xamarin forms, он совместим с настольным компьютером/win10 и может перейти на мобильный телефон. Используйте MVVM. Конечно, это совершенно другая философия развития.
Если win7, используйте WPF, но там нет мобильного маршрута.
Но и MVP тоже, только с MVP вы будете делать все вручную. MVVM много встроен во многих отношениях Microsoft.
В пользу MVP: вы можете сохранить немного больше кода, связанного с winforms, но почти все они должны будут застрять в представлениях, что ослабит преимущество обновления. Конечно, это также даст вам "выход", если время закончится - по крайней мере, некоторые из них будут переработаны/переписаны.
Моя рекомендация: найдите новую потребность ваших пользователей, запустите новое приложение с использованием современной архитектуры. Если нет, выполните рефакторинг/переписывание.
Что касается шаблона репозитория: это мощный инструмент. Обратите внимание, что не следует вводить репозитории в объекты вашего домена. Они должны быть подключены на более высоком уровне - объекты, которые вызывают объекты домена. Это слой между докладчиками (или моделями представлений) и моделью предметной области. Доменные объекты не должны знать о репозиториях, они не должны знать, как сохранять/загружать себя. Они не должны иметь прямых ссылок на другие объекты домена.
Конечно, репозитории будут знать о ваших доменных объектах, вы должны внедрить его, отображение будет в них.
Это перемещает некоторый код в этот слой (DDD называет его "сервисным" уровнем кода, другие называют его прикладным уровнем, многие не знают о его полезности). Примечание: наличие доменных объектов, знающих об абстракциях репозиториев, так же плохо сочетается с ними.
Все объекты, так что вы можете делать по каждому элементу (счета на счет клиента.Счета)...' ... и затем поместите эту логику в клиента. Это не сок. Он охватывает оба бизнес-объекта. Не помещайте ссылки или список ссылок на один бизнес-объект в другой. Поместите эту логику, которая касается обоих, в слой ddd-services. (обратите внимание, что это не бизнес - объекты-они берут ссылки на бизнес-объекты) Это также решает проблему n+1. это также решает 95% несоответствий импеданса объектов-реляций. Это позволяет вам делать то, что вы хотите в своем приложении, и сохраняться в SQL, не съедая сухие хлопья отрубей NoSql. Многое встает на свои места.
Стежок бизнес-объектов и их кол-во идентификаторы ФК идентификаторы. Некоторые будут утверждать, что это утечка реализации SQL в объекты. Но если вы все равно храните данные в SQL, то у вас нет выбора. И он не несет в себе недостатка этих утечек esp. если вы помещаете их в строковые типы в своих объектах, то он может содержать int, guid, составной ключ и т. д. все, что ты можешь изменить. Другими словами, Не беспокойтесь о такой "утечке".
Конечно, не заходите слишком далеко, иначе ваши бизнес-объекты будут анемичными. Для простых случаев инъекция параметров допустима до тех пор, пока вы не сохраняете ссылку на другой бизнес-объект. Пример (код в объекте слоя ddd-services, который получает другие инъекции - cust.GetAmountDue(от acct в аккаунтах, где acct.custid==cust.id)). Здесь вы ввели перечисляемый счет - по параметру - в метод GetAmountDue клиента. Нет инъекции конструктора/свойства - это удержание ссылки!
Для вашего 3-го вопроса, если вы используете EF, пропустите репозитории, или вы будете дважды оборачивать свою БД. Насколько мне известно, большинство платформ имеют издевательской причине в для модульных тестов. Знание того, что бизнес-объекты не должны сохраняться сами по себе, помогает этому иметь смысл. В вашем слое DDD-services сопоставьте модели EF с объектами домена. Ради всего хорошего в мире используйте AutoMapper (etc) или доменные объекты ExpandoObjects/Propertybag с соответствующими именами свойств (цикл через них для отображения), в противном случае будьте готовы закончить все это в поисках ошибок, которые вы сделаете обезьяньим кодированием материала.
Если это все слишком много, помните - твердое не делай и не умирай. Это может сделать вещи только на 20-30% лучше, чем хорошо написанная ОО-программа, которая приняла разумно консервативный подход с точки зрения причудливости, и пока вы не добьетесь успеха в этом, скорее всего, это сделает вещи на 20-50% хуже, чем это!
Onur ERYILMAZ
Спасибо за ответ.
Как я понимаю, вы рекомендуете начинать с нуля с использованием форм WPF или Xamarin. Я подумаю об этом.
Но у меня есть несколько вопросов.
1 - Вы говорили об объектах домена и бизнес-объектах. Как я понимаю, мне нужно отделить свои объекты.
Например:
EF создает объект на основе моей схемы базы данных следующим образом;
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;
}
}
Итак, когда пользователь хочет создать новую компанию, сначала я получаю входные данные пользователя и помещаю их в свой объект компании, а затем преобразую этот объект в объект EF с помощью AutoMapper, а затем отправляю объект EF в репозиторий, чтобы сохранить его?
fastal
Я думаю, что вы находитесь на пути, который будет работать.
Я бы подумал, что если вы все еще собираетесь использовать репозитории, сделайте сопоставление между объектами EF и вашими объектами внутри репозиториев. Вот отличный пост, который более подробно рассказывает о том, как это сделать:
https://stackoverflow.com/questions/24588838/entities-vs-domain-models-vs-view-models
Я имею в виду одно и то же, когда говорю "доменные объекты" и "бизнес - объекты", но, как я вижу, не все авторы делают это. В этом посте создается впечатление, что они могут подразумевать объекты EF под объектами "домена" - хотя я не уверен, что это кажется нестандартным способом сделать это. Извините за использование обоих терминов.
Вы увидите, что большинство людей не говорят о слое "DDD-Services" для составления и интеграции Ваших бизнес-объектов. Этот пример не является исключением. Просто освободите для него место в своем проекте - это не тот слой, на который нужно сопоставлять все свойства или "через" - Когда у вас есть какая-то сложная межобъектная логика, хотя, возможно, имеет смысл создать новый объект в слое сервисов, внедрить бизнес-объекты, которые нуждаются в работе, и выполнить работу там, чтобы избежать смешивания ссылок на объекты. Обратите внимание - это около 10% логики, которая действительно нуждается в этом, но, как правило, это более сложная логика ;-)
Если ваши бизнес-объекты не содержат ссылок на репозитории, это упрощает модульные тесты, меньше возможностей для макетирования... Я бы не рекомендовал издеваться или абстрагировать ваши бизнес - объекты для тестирования объектов доменного уровня-это приведет к менее детализированным единицам, поскольку они зависят от бизнес-объектов, но если ваши бизнес-объекты имеют хорошие тесты, это смягчит ситуацию. Это даст вам большую часть ценности тестов без технического долга абстрагирования ваших бизнес-объектов (что требует больше, чем дает). Если этот последний абзац не имеет смысла, проигнорируйте его ;-)