In this and few further posts I’d like to show some concepts regarding application structure. First I present way to communicate with DB that I think will be suitable here.
So, assumption is that we have SQLite database with one table: “Books” that contains 27 fields (described in previous post). We want OlGatherer to be as easy to maintain and extend as possible, so we would like to work with as many interfaces as we could. As I’m not very good programmer/application architect/software engineer, so I believe that application concept will be evolved and changed in time. If I would work with concrete classes only, any change in assumptions/requirements would force these classes to be completely changed. On the other hand interfaces make that changes will be easier to implement – we won’t have to change large parts of the code, but rather single lines (I hope). In general, it will take be much less effort to do changes with interfaces than without them. I’ve read nice book about patterns recently, and noticed that there is a Repository pattern. I will explain idea of this pattern in a moment.
I mentioned earlier that we have database with one table. I would like to get data from this table using Linq technology. .Net framework since 3.5 version have Linq2SQL that allows user to get data from SQL Servers in a quite easy way. As we are going to use SQLite, I had to find other Linq provider. On the stackoverflow forum I found that DbLinq is the best option at the moment (unfortunately I cannot make DbMetal to work properly, but this is topic for the next post). So, Linq2Sqlite will be used.
Then we have now: SQLite database -> Linq2Sqlite -> Rest of the application. This situation is depicted on the scheme below.
We can introduce Repository pattern then:
As we can see, it’s very simple:
IRepository<T> is a generic interface that contains basic CRUD methods (Create, Read, Update, Delete). IBookRepository<Book> extends it with methods that are specific for book collections only - GetByIsbn(string isbn); and GetByAuthor(string author);. (Of course this isn’t full list of methods/properties. It’s decreased to the minimum for sake of readibility).
Book class represents one entity in the Books table, so it will have 27 fields and no methods (I assume that).
BookRepository implements IBookRepository<Book> interface.
Simple, isn’t it? Let’s imagine what we have to do if we would like to add new kind of collection, of wines for example. It cannot be simpler – all we have to do is to add IWineRepository<Wine>, that contains methods specific for wines, e.g. GetByVintage(int year); or GetByColour(string colour);.
Next add Wine class containing fields describing Wine bottle, and create WineRepository that implements above interface. Simple and elegant.
There is one issue that I’m thinking about all the time – how to merge Repository with Linq2SQLite in proper manner? I’m still thinking about it and I hope that I will figure it out very soon. I think also about adding Factory pattern to manage Repositories, but itsn’t necessary right now, so I will place this idea on “TODO” list :)
Best regards, Paweł