Зараз я працюю соло розробником свого поточного проекту. Я успадкував проект від іншого розробника, який відтоді покинув компанію. Це веб-додаток із стилем перегляду моделей у C #. Він використовує Entity Framework для реляційного відображення об'єктів. І існує два різних набори класів для типів у доменній моделі. Один набір використовується для взаємодії з ОРМ, а інший використовується як моделі в системі MVC. Наприклад, можуть бути два класи:
public class Order{
int ID{get;set;}
String Customer{get;set;}
DateTime DeliveryDate{get;set;}
String Description{get;set;}
}
і
public class OrderModel{
String Customer{get;set;}
DateTime DeliveryDate{get;set;}
String Description{get;set;}
public OrderModel( Order from){
this.Customer= from.Customer;
// copy all the properties over individually
}
public Order ToOrder(){
Order result =new Order();
result.Customer = this.Customer;
// copy all the properties over individually
}
}
Я можу придумати кілька недоліків такого підходу (більше місць для зміни коду, якщо щось змінюється, більше об'єктів, що сидять навколо пам’яті, більше часу витрачається на копіювання даних навколо), але я не дуже впевнений, у чому тут переваги. Більше гнучкості для модельних класів, мабуть? Але я міг би отримати це, підкласируючи також сутність класів. Моя схильність полягала б у об'єднанні цих двох класових груп або, можливо, модельні класи будуть підкласами класів сутності. Тож я пропускаю щось важливе тут? Це загальна модель дизайну, про яку я не знаю? Чи є вагомі причини не переживати рефактор, про який я замислююся?
ОНОВЛЕННЯ
Деякі з відповідей тут змушують мене зрозуміти, що в моєму первинному описі проекту бракувало важливих деталей. Існує також третя група класів, які існують у проекті: класи моделей сторінки. Саме вони фактично використовуються як модель, що підтримує сторінку. Вони також містять інформацію, яка є специфічною для інтерфейсу, і не зберігалася б із замовленням у базі даних. Прикладним класом моделі сторінки може бути:
public class EditOrderPagelModel
{
public OrderModel Order{get;set;}
public DateTime EarliestDeliveryDate{get;set;}
public DateTime LatestAllowedDeliveryDate{get;set;}
}
Я повністю бачу, що корисність цієї третьої групи тут відрізняється, і не планую об’єднувати її з чимось іншим (хоча я можу перейменувати її).
В даний час класи в групі моделей також використовуються API програми, і мені також було б цікаво почути, чи це хороша ідея.
Я також повинен зазначити, що клієнт, представлений тут як рядок, повинен був спростити приклад, не тому, що він насправді представлений таким чином у системі. Фактична система має замовника як виразний тип у доменній моделі, має свої властивості