Develop layers first having in mind transition to Dependency Inversion principle and Inversion of Control at a later stage?

Question

I have a base applicaiton that will evolve. Right now UI includes BLL. DAL is a separate library that serves its purpose.

I dont have time to do everything right now, so i want to bypass patterns that help with decoupling (IoC , DI as i have been proposed here).

I would like to create my BLL and have a reference for the DAL directly. This will give me the opportunity to start creating separate UIs that i need now.

My question is can i do it? Can i focus right now in creating my 3 layers and gradually apply design patterns to make my code better?

Added Info:

I have the luxury of the time because my first app will not be used during the development of the second one. So i will have the time to optimize my coding structure. The question what i can do know to split UI into UI + BLL as effective as i can . On my mind is that i will just move the DAL init in BLL and put in UI the BLL init. Is there something else i can do that it will help me more when applying IoC/DI later on?

Answer 1

You can set up "poor man's dependency injection", using this kind of structure:

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())
    {
    }
}

Answer 2

Getting a working product quickly can often be the most important thing so taking a concious decision to skip over some engineering practices may be the right one.

However, you need to ensure you are making the right trade-offs. Refactoring is not free and dealing with technical debt needs to be planned for.

The path of least resistance once the end users see your initial version is usually to keep adding functionality over revisiting initial design decisions.

To put it another way, once version 1.0 is in the wild you will have a hard job persuading management that you need to spend a large number of man days reworking things under the hood for no perceivable change or benefit to the customer.

Without knowing the details of your app or requirements it's impossible to give concrete advice. In general though spending some time up front thinking about the design is orders of magnitude quicker and simpler than trying to do the same thing some way into development.

Answer 3

I like very much the "debt" metaphore in this case. The quicker you push to deliver your first working version and compromise on code quality and engineering best practices, the longer and harder it is going to be to get any new change requests implemented.

It is up to you to decide how much "in debt" you want to get. Think that creating a product from scratch is a unique opportunity to show your qualities, if you deliver it in say one month but need five months to implement a few simple change requests your credibility and reputation will suffer and they will replace you.