WPF Architecture with Business Layer and DAL

Question

Im starting a new application in WPF and I want it to have a good architecture so that it can be maintainable. Im using Entity Framework and what I planned so far is.

• View Layer: One project (startup) with the startup view, and main menus. Different projects for each type of view, for example, if I have views related with Books then I'd have a project named BooksView with all the views.

• Business Layer: One project for each type of Business Class, for example BusinessBooks. Each one would have a Repository with the specific operations and any helpers to do calculations if needed.

• Data Acess Layer: It contains a folder named Entity Framework with the DBContext and with the T4 generated classes and with a class named ContextCreator which has the following code:

public class ContextCreator : IDisposable
{
    private MesaOperativaDB context;

    public ContextCreator()
    {
        context = new MesaOperativaDB();
    }

    public MesaOperativaDB getContext()
    {
        return context;
    }

    public void Dispose()
    {
        context.Dispose();
    }
}

Then a view would use the static repository of any project of the Business Layer that needs, and this repository would use the class above to get the DBContext and use it like this:

    public static List<Novedades> GetNovedades()
    {
        using (ContextCreator db = new ContextCreator())
        {
            IQueryable<Novedades> novedades = db.getContext().Set<Novedades>().AsQueryable();
            return novedades.ToList();
        }
    }

Is this approach any good? Thank you in advance guys.

If its a client side application only then that is pretty good separation of concerns — liquidsnake786, Dec 02 '14 at 14:25

score 6 · Accepted Answer · edited May 23 '17 at 11:33

Though I am quite not sure of your application scale but it seems good to me that you have started on a right path for separation of concerns.

But you may need to rethink if creating separate project for each category of views does not introduce unnecessary complexity.

Again I am not sure if you are new to WPF, but for the View layer for better maintainability, loose coupling and hence testability etc., MVVM is the best chosen pattern to organize things in place. For getting MVVM in place you may handcode everything from scratch or there are nice frameworks available like:

MVVM Lite

Assisticant

Also if you are planning towards a relatively big(layman term!!)/enterprise class application and since you are looking for highly maintainable, flexible application you may consider using PRISM framework from Microsoft. Prism Guidance and downloadable PDFs etc.

Once you finalized on the View part, the you need to focus on Validations for your app and whether you would be implementing validations in the ViewModel or in your domain objects. Assisticant framework has some good domain-centric validation mechanism built into it.

For the Data access layer, since you chose to go with EF, from my understanding so far, the Unit-Of-Work with Repository pattern would greatly help you to gain extensibility, testability etc. features.

If you are planning high on unit testability and loose coupling of your application, you need to consider Inversion of Control and Dependency Injection perhaps with a suitable framework.

Here you can check a WPF application framework to understand on how to organize different areas of a WPF application in a layered approach.

Hope this may help you to dig further.

WPF Architecture with Business Layer and DAL

1 Answers1