У меня есть класс Student, который необходимо сохранить в базе данных. У меня есть методы, которые создают и обновляют эти студенты (CreateStudent, UpdateStudent) и прямо сейчас, структура этого класса студент:Рекомендации по структуре классов
public class Student
{
public int ID { get; set; }
public string FirstName { get; set; }
}
Теперь то, что я имею в виду мой CreateStudent принимает объект Student:
public int CreateStudent(Student newStudent);
Однако, поскольку этот ученик является новым, идентификатор не будет сохраняться (или не должен сохраняться) в базе данных. Но пользователю метода кажется непонятным, что так оно и работает. Например, я использовал CreateStudent, но прошел Student.ID из 6, метод CreateStudent игнорировал бы ID, так как это создает ученика. Тем не менее, я пытаюсь найти что-то более ясное. Теперь я хочу попробовать отделить идентификатор до интерфейса, который будет доступен только в том случае, если в базе данных уже есть Студент. Вроде как это:
public IEntity
{
int ID { get; set; }
}
public interface IUnknownStudent
{
string FirstName { get; set; }
}
public interface IStudent : IUnknownStudent, IEntity
{
}
Тогда при использовании CreateStudent, я прохожу IUnknownStudent (не ID). Только при получении или обновлении я буду использовать реализацию с идентификатором. Но я не уверен, есть ли у него какие-либо проблемы с момента его первого раза, когда я пытаюсь это сделать, и мне было интересно, могут ли опытные ребята здесь дать некоторые советы.
EDIT:
CreateStudent() находится на отдельном классе, StudentLogic.
Не означает, что имя 'CreateStudent' просто прямо вверх ** подразумевает **, что ученик ** не создан **, и поэтому идентификатор будет получен _ из базы данных_? Нет необходимости в отдельных интерфейсах.В противном случае, я думаю, вам понадобится «IKnownStudent», который больше работает и глупо. – MickyD
мои 2 цента: как мысленный эксперимент, посмотрите, как далеко вы можете просто создать систему со студенческой записью, являющейся не чем иным, как картой ключевого значения пар. выяснить минимальный набор функций (статические методы, которые, как я полагаю), необходимо действовать на этих картах, чтобы удовлетворить цели вашей программы. не предполагайте, что классы (или интерфейсы) не нужны, пока вы не достигнете точки, когда ваш дизайн начнет убеждать вас в противном случае - в этот момент класс или два могут всплыть и сделать действительно убедительный случай для себя – lispHK01