Разрабатывать слои сначала, имея в виду переход к принципу инверсии зависимостей и инверсии управления на более позднем этапе?

У меня есть базовое приложение, которое будет развиваться. Прямо сейчас пользовательский интерфейс включает BLL. DAL — это отдельная библиотека, которая служит своей цели.

У меня нет времени делать все прямо сейчас, поэтому я хочу обойти шаблоны, которые помогают с развязкой (IoC, DI, как мне было предложено здесь).

Я хотел бы создать свой BLL и иметь ссылку на DAL напрямую. Это даст мне возможность начать создавать отдельные пользовательские интерфейсы, которые мне нужны сейчас.

Мой вопрос, могу ли я это сделать? Могу ли я прямо сейчас сосредоточиться на создании трех слоев и постепенно применять шаблоны проектирования, чтобы сделать мой код лучше?

Добавлена ​​информация:

У меня есть роскошь времени, потому что мое первое приложение не будет использоваться при разработке второго. Так что у меня будет время оптимизировать структуру кода. Вопрос, что я могу сделать, чтобы разделить пользовательский интерфейс на пользовательский интерфейс + BLL настолько эффективно, насколько я могу. На мой взгляд, я просто перенесу инициализацию DAL в BLL и поставлю в пользовательский интерфейс инициализацию BLL. Есть ли что-то еще, что я могу сделать, что это поможет мне больше при дальнейшем применении IoC/DI?


person e4rthdog    schedule 12.12.2012    source источник


Ответы (3)


Вы можете настроить "внедрение зависимостей бедняка", используя такую ​​структуру:

public class MyEndClass
{
    private readonly IDependency dependency;

    public MyEndClass(IDependency dependency)
    {
        this.dependency = dependency;
    }

    // temporary constructor until we introduce IoC
    public MyEndClass() : this(new Dependency())
    {
    }
}
person levelnis    schedule 12.12.2012
comment
Так что мой DAL будет таким. Dependancy() относится к конструктору моего BLL? - person e4rthdog; 12.12.2012
comment
Наоборот, ваш BLL будет зависеть от DAL, в идеале через интерфейс. Точно так же ваш уровень презентации будет зависеть от BLL (или столько, сколько ему нужно) - person levelnis; 12.12.2012
comment
Понял, впереди много чтения. Уже подписался на видеоролики по программной инженерии PultSight. Отметка вашего ответа. - person e4rthdog; 12.12.2012

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

Тем не менее, вы должны убедиться, что делаете правильный выбор. Рефакторинг не является бесплатным, и необходимо планировать работу с техническим долгом.

Путь наименьшего сопротивления после того, как конечные пользователи увидят вашу первоначальную версию, обычно состоит в том, чтобы продолжать добавлять функциональность, а не пересматривать первоначальные дизайнерские решения.

Иными словами, как только версия 1.0 будет выпущена, вам предстоит тяжелая работа, чтобы убедить руководство в том, что вам нужно потратить большое количество человеко-дней на доработку вещей под капотом без видимых изменений или выгоды для клиента.

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

person Paolo    schedule 12.12.2012
comment
Я на 100% поддерживаю ваше мнение. Однако у меня есть преимущество. После того, как я дал v1 текущего приложения, я включил время, которое мне нужно, в мою оценку для v1 следующего приложения. То есть я думаю, что у меня будет время сломать слой пользовательского интерфейса в пользовательском интерфейсе, BLL, прежде чем выпустить второе приложение. хорошо здесь то, что первое приложение не понадобится, потому что это приложение для инвентаризации, которое запускается один раз в год. Мой истинный вопрос заключается именно в коде, что мне нужно сделать, чтобы иметь как можно более легкую работу по применению IoC/DI. - person e4rthdog; 12.12.2012
comment
Всегда убедитесь, что вы кодируете интерфейсы, а не реализации. Это проложит путь для IoC, когда он вам понадобится. - person levelnis; 12.12.2012
comment
@levelnis: Отлично, это то, что я искал. Не могли бы вы дать ответ и уточнить на простом примере? - person e4rthdog; 12.12.2012

В данном случае мне очень нравится метафора «долг». Чем быстрее вы поставите свою первую рабочую версию и пожертвуете качеством кода и лучшими инженерными практиками, тем дольше и сложнее будет реализовать любые новые запросы на изменение.

Вам решать, сколько «в долг» вы хотите получить. Думайте, что создание продукта с нуля — это уникальная возможность продемонстрировать свои качества, если вы сделаете его, скажем, за один месяц, но вам потребуется пять месяцев, чтобы реализовать несколько простых запросов на изменение, ваше доверие и репутация пострадают, и они заменят вас.

person SkyWalker    schedule 12.12.2012
comment
Я понял вас, но, пожалуйста, прочитайте обновление, которое я разместил в своем первом посте. Я думаю, что позволил себе PSI в свой долг :) Мне просто нужно знать, какие способы я могу реализовать на уровне без IoC. и какой из этих способов лучше подходит для последующего перехода на IoC - person e4rthdog; 12.12.2012