Нужна помощь

Question

можете проверить на наличие ошибок?

P.S. если плохо видно сделайте Zoom страницу. (можно нажать Ctrl + '+') или (OpenImageInANewTab)

Answer 1

эта библиотека для работы с базой данных FoodStore. 

У меня есть идея реализации. но иногда сомнения тоже появляются. ибо некие вещи трудно уловить.

например есть такая трудность:>

// таблица Deliveries содержит поле Order, это объект типа Orders (тут имееться ввиду Связь 1:1), а ведь можно просто хранить OrderId типа Int, и какой же вариант надо использовать. Просто этот Объект Order в таблицу вряд ли запишется. а если запишется то его нельзя просмотреть, ну и она вообще не запишется кажется, просто станет ключом?

public class Delivery
    {
        public int DeliveryId { get; set; }
        public virtual Order Order { get; set; }
        public bool Awaiting { get; set; }
        public virtual Worker WorkerDelivery { get; set; }
        public int DeliveryMoneyPool { get; set; }
        public DateTime LastModified { get; set; }
        public bool Complete { get; set; }
        public bool Canceled { get; set; }
        public bool PackageOrder { get; set; }
        public Delivery()
        {
            Order = new Order();
            WorkerDelivery = new Worker();


        }
    }

// но в таблице Orders нет поля Delivery, то есть свзязь односторонняя получается? Ок Ладно. И опять, может надо использовать OrderId в таблице Deliveries,  и тогда в таблице Orders можно будет хранить DeliveryId (а можно и не хранить. . .), но если так(хранить) то у некоторых Order могут не быть DeliveryId, а у некоторых могут быть. То есть этот DeliveryId типа Int всегда будет инкрементироваться просто так (да и вообще это чушь какая то)

public class Order //заказ
    {
        public int OrderId { get; set; }
        public virtual Customer Customer { get; set; }
        public virtual List<Product> Products { get; set; }
        public DateTime DateOfOrder { get; set; }
        public virtual Worker Cashier { get; set; }
        public virtual OrderStatus OrderStatus { get; set; }
        public virtual Payment Payment { get; set; }
        public DateTime LastModified { get; set; }
        public Order()
        {
            Products = new List<Product>();
            Customer = new Customer();
            Cashier = new Worker();
            OrderStatus = new OrderStatus();
            Payment = new Payment();
            LastModified = DateTime.Now;
        }

вообщем вопрос таков.  в таблице Deliveries надо хранить (Order)Order или (int)OrderId

P.S. Голова болит уже от этого всего. 19 раз переделывал потому что впервые такое делаю

Answer 2

"а ведь можно просто хранить OrderId типа Int, и какой же вариант надо использовать. Просто этот Объект Order в таблицу вряд ли запишется. а если запишется то его нельзя просмотреть, ну и она вообще не запишется кажется, просто станет ключом?" - вы проектируете сущностные классы используя ООП, а мыслите как пректировщик реляционной БД. Как раз наоборот, можете не писать Int, а оставить только поле Order. Если связи нет, то объет будет содержать Null. В случае опциональных связей, используй Nullable<int>. А что касается записи объекта в БД, то это не проблема уровня сущностных классов, а уровня ORM.

"но если так(хранить) то у некоторых Order могут не быть DeliveryId, а у некоторых могут быть. То есть этот DeliveryId типа Int всегда будет инкрементироваться просто так (да и вообще это чушь какая то)" - Nullable<T>.

---

Сделаем содержимое сообщества лучше, вместе!

Answer 3

// таблица Deliveries содержит поле Order, это объект типа Orders (тут имееться ввиду Связь 1:1), а ведь можно просто хранить OrderId типа Int, и какой же вариант надо использовать.

Для начала, как мне кажется, вам следует начать с освоения теории реляционных баз данных, с освоения основ языка SQL, потому что явное непонимание всего этого.

В таблицах БД при указании связей между ними не хранятся объекты. Хранятся лишь первичные и внешние ключи, с помощью которых и реализованы связи.

Просто этот Объект Order в таблицу вряд ли запишется. а если запишется то его нельзя просмотреть, ну и она вообще не запишется кажется, просто станет ключом?

ORM, такие как EF, сами отслеживают связи, и считывают записывают дочерние-родительские объекты. При этом, повторюсь, в самих таблицах БД нет полей типа Order или Delivery, а есть родительские и внешние ключи. EF на основе этих ключей создаёт свойства в коде, по которым можно прозрачно получать доступ к связанным объектам.

Многое зависит от выбранного подхода: Code First или Database First.

// но в таблице Orders нет поля Delivery, то есть свзязь односторонняя получается?

Более того, при подходе DDD связь вообще можно не указывать. В этой статье автор советует вообще отказываться от лишних связей, которые нужны редко и лишь для специфичных целей.

Отмечу, что эта серия статей специфична, и не даёт основ работы с БД, а рассчитана именно на освоение проблемно-ориентированного проектирования.

И опять, может надо использовать OrderId в таблице Deliveries,  и тогда в таблице Orders можно будет хранить DeliveryId (а можно и не хранить. . .), но если так(хранить) то у некоторых Order могут не быть DeliveryId, а у некоторых могут быть.

Ну да, это нормально. При проектировании БД можно разрешить не иметь связей.

То есть этот DeliveryId типа Int всегда будет инкрементироваться просто так (да и вообще это чушь какая то)

С чего это он будет инкрементироваться просто так? Если это тип identity, то при каждой новой вставке будет новое значение поля, но созданные ранее не изменятся.

вообщем вопрос таков.  в таблице Deliveries надо хранить (Order)Order или (int)OrderId

В упомянутой выше статье авторша предлагает использовать guid - это позволит создавать значения ключей в коде, а не в БД. То есть при вставке значений не будет лишнего обращения к БД для получения сгенерированного значения ключа.

Answer 4

я использовал code first, и в youtube поискал, нашел кое что где делается совсем обратное. если судить по видео, то мне следует использовать оба типа (Order) Order и (int) OrderId.

Answer 5

Это обычные соглашения для Code First. Т.е. EF наличие двух свойств нужно для генерации отношейний между таблицами в БД (внешних ключей). Это наиболее простой вариант. Можно не использовать поле с типом int, а неоходимую информацию передать в БД с помощью Fluent API при инициализации. Но в вашем случае, для простоты лучше оставить всё как есть.

---

Сделаем содержимое сообщества лучше, вместе!

Answer 6

если честно досихпор парюсь какой мне нужен вариант, простой (и потом если вдруг делать дальше, то никчему хорошему не приведет), или же правильный (которые довольно сложно сделать)

Answer 7

на что нужно обращать внимание при осуществлении платежей(покупка товара) в приложении. 

Answer 8

"я не знаю t-sql, и предпочтительней метод code first, полагаю dbForge Studio ничем не поможет" - универсального рецепта вам тут никто не даст. Каждое приложение уникально по своему. В целом надо учитывть такие критерии как безопасность и надёжность (отказоустойчивость). Если речь идёт о работе с платёжными системами.

---

Сделаем содержимое сообщества лучше, вместе!