Is this two programs or just one?

[rayden54]

I've tossing around ideas to try to make a sort of DVD library program. On one hand you've got the sort of librarian side (adding new DVDs, assigning them to different shelves, marking if they're part of a set). On the other you've got the library patron side (looking up DVDs, seeing if they're checked in or out).

 

In my program, since this is just for my DVDs, I'll be both the librarian and the only patron.

 

Maybe two modules in one program? I don't know?

 

I've been trying to make this project go for a while now, but last time I got buried under a mountain of stuff I don't understand. How the hell is an abstraction of an abstraction of an abstraction (at times 4 layers deep) easier to read!??

[Nineshadow]

They are different things, yes, but they should be included in the same program. Anyway, here's a few ideas of mine. DVDs will be objects. They will have a string as their names or maybe an id, so you can keep track of them. They will also have an audio file, from which you could extract other Metadata, like the artist name. Anyway, you'll need to make a database of DVDs, add functionality to add DVDs, remove them, modify contents, and other stuff you will want to do. This would be really basic.

[rayden54]

It should be basic. I've been bogged down in trying to write it for months now. I can't get anyone to answer simple questions like "where does the database connection go and what does it look like" without people mentioning a half dozen design principles that I've never heard of. The examples I've seen are either incredibly complex geared at enterprise applications where simple data storage requires no less than 7 different files (not counting a an individual class file for each object). Or they're highly simplified and BS their way through the part I actually need (yes I already know how WPF does data binding, I need to know how to make the actual database connection).

[Nuluvius]

I can't get anyone to answer simple questions like "where does the database connection go and what does it look like" without people mentioning a half dozen design principles that I've never heard of.

 

Then perhaps don't you think that you should take yourself off and go and do some research in order to better understand them then?

 

In any event, try not to overthink things, break your requirements down into a set of concerns:

1. You have entities in the form of DVDs
2. You want to manage these entities in the form of Search, Create, Read, Update, Delete (SCRUD)
3. You want to have some other entities that can be associated with your DVD entities (users/patrons checking out DVDs)

This constitutes a rather simple database model in concept. You haven't eluded to needing any assistance with it however so I will assume that you have a clear relational model already worked out that you are happy with.

 

The overall architectural design of your application is also rather simple. Since you have already eluded to using WPF and already being familiar with how things work there then I will assume that you are using the MVVM design pattern (because otherwise kittens will be dieing). Your database then simply constitutes the Model portion, you will consume this within your business logic which you will have layered into your ViewModel and obviously bind that up to your View.

 

I would suggest that you use a framework such as the Entity Framework or NHibernate which you can easily pull in via NuGet to connect and communicate with your database as this will make your life very easy. You can approach it in one of two ways; either Model First where you visually design the table structure and relations or Code First where you do the same essentially but from a code based approach. Both approaches can generate the DDL for direct database generation or vice versa you may generate the Model from the database.

 

Once you have your database wrapped I would suggest that you put the specific implementation behind an interface so that you may; extend it later, test it and also completely implement to a different database later. This is probably where people are telling you that you need to go and look at some design patterns. Please go and look at the Repository pattern because this is the correct way to do things like this. You will have far cleaner and understandable code as a result. Any monkey can hack and chop code about but it will certainly be crap. I don't presume to know or understand you (yet), so are you happy with writing crap?

 

Remember that the Agile methodology dictates that one should always get the simplest and most concrete thing implemented and working first, refactoring/generalization comes afterwards.

[rayden54]

Then perhaps don't you think that you should take yourself off and go and do some research in order to better understand them then?

No, I don't. I'm trying to write a simple app that WORKS. Not trying to read 200 books and still not understanding it, The rest of your post is exactly the sort of thing I'm trying to AVOID. I've already looked into the Entity Framework and code first and all that other stuff. FOR SEVEN FREAKING MONTHS NOW and I'm no closer to understanding how it works. My program's NOT the sort of enterprise app where that stuff is even useful  BTW if you ask, about half the people you meet will say use repository, the other half will say avoid it like the plague. Either way I know the "put it behind an interface" does not lead to "cleaner and understandable code." Cleaner maybe if you mean using no less than 7 different files to do what should be done with one or two.

 

I'm not trying to build some enterprise app where code reuse and abstraction of abstractions are a good idea, let alone necessary. For all the stupid principles people keep talking about, not one single person seems to care that the most important should be "do not make things more complicated than they need to be."

[Nuluvius]

Well now, that certainly told me didn't it?

 

Not trying to read 200 books and still not understanding it

 

I would never advise such a torture on anyone. In any event books in today's industry are of rather limited value in my opinion.

 

No, I don't. I'm trying to write a simple app that WORKS.

 

The rest of your post is exactly the sort of thing I'm trying to AVOID.

 

...not one single person seems to care that the most important should be "do not make things more complicated than they need to be."

 

You seem very quick to go on the offensive and I can certainly understand that it's probably down to frustration but at the same time you missed a key point in my post that specifically addressed these concerns of yours:

 

Remember that the Agile methodology dictates that one should always get the simplest and most concrete thing implemented and working first, refactoring/generalization comes afterwards.

 

No interfaces, so generalizations, no abstractions, just a concrete implementation - simply get it working first and then make it pretty later.

 

BTW if you ask, about half the people you meet will say use repository, the other half will say avoid it like the plague. Either way I know the "put it behind an interface" does not lead to "cleaner and understandable code." Cleaner maybe if you mean using no less than 7 different files to do what should be done with one or two.

 

...all the stupid principles people keep talking about...

 

My program's NOT the sort of enterprise app where that stuff is even useful

 

I'm not trying to build some enterprise app where code reuse and abstraction of abstractions are a good idea, let alone necessary. 

 

Given the above statements I think that the key problem here is that you really are not understanding things clearly. Maybe you have had so much information (both too complicated, too simple and too contradictory) thrown at you at once that you have become so confused and turned in so many circles that your head has come right round and proverbially traveled up your own backside? That's fine and it's an easy situation to fall into.

 

Regardless of the type of application you are trying to write, design patterns still apply and can be interpreted as simply what they sound like; patterns or blueprints that have been established or recognized as methods of how to implement things that allow for good engineering/design principles. They offer logical encapsulation for specific concepts and provide clean, readable, recognizable and extensible code when they are used right. That said one should also be mindful that this description should also be taken quite literally, in other words as blueprints or guidelines they are open to interpretation.

 

There's no reason that an implementation of the Repository pattern should result in '7 different files to do what should be done with one or two' as you put it.

 

Let's examine this from the Agile point of view... We need to connect to a database, and we would like to keep this databasey kind of stuff out of our main code so as not to spill and pollute code that's got nothing databasey to do.

 

The way you could approach this concept is to make yourself a simple class called something like Datastore. In there you could put logic to connect to and disconnect from your database surfacing this up as simple Connect & Disconnect methods. The next thing you might like is some methods that expose things like Search, Create, Update, Delete and so on... for the manipulation of the data in your database.

 

You might end up with something like this (pseudocode):

class Datastore{   public bool Connect() {...}   public bool Disconnect() {...}   public bool Create(Entity) {...}   public bool Delete(Entity) {...}   public bool Update(Entity) {...}   public List<Entity> Search(Criteria) {...}   ...} 

What we have just made is a very concrete class that deals with one database and a very specific piece of data - an Entity. This will give us exactly what we want, a way to connect to and disconnect from our specific database and a way to manipulate our specific data. We can instantiate this 'Datastore' in our VIewModel (our business logic) and make direct use of it no problem right?

 

However let's say that we are talking to a MSSQL database and we also needed to talk to a MySQL database. Or far more importantly what if we wanted to test our code that consumes and uses our Datastore. Well currently it can only to talk to a database so we would have to guarantee that we could always have access to and the use of that... but in test we really can't do that. Moreover we don't want to be coupled to a specific database all the time either. What we want to be able to do is to mock out our Datastore. In other words we want to have a Datastore that we can consume that has no need for a physical database - we can put whatever we want into its methods so that we can affect the system under test.

 

Think about this; what we have just done by making our concrete implementation is expose a set of public methods - an API or an Interface to our class or our implementation detail. Just take a look at the pseudocode above...

 

It shouldn't be that much more of a jump to consider at this point that we can simply lift just these public methods off of our very specific class and put them into a contract - an interface to which we can implement a few different kinds of Datastore. At this point we will have two files (not 7); a concrete Datastore for our specific database and an interface defining its public contract. We could then add another class and have a mock Datastore so that we can test our code to verify that it's doing what we think it should be doing.

 

If we wanted to take things one step further we would also define an interface for our Entity because that is also currently very specific right now.

 

The minute you break encapsulation and spill your implementation details is when you will foul your code and end up with a mess of tangled spaghetti. You will come back to it in a few months and have absolutely no idea what any bit of it is trying to do and will spend hours trying to figure it all out again. Moreover if you try to extend or change any part of the behaviour of your application you will be in for a painful ride indeed.

 

Any chimp can hack and smash code together in a big file and get the results they are after but the net effect will be complete garbage. It will work but it will be a monolithic nightmare of an abortion.

 

This is why we have design patterns and engineering principles; those 'stupid principles people keep talking about' as you put it exist for the sole reason of helping you write good code and build a well designed application. They apply to anything you write at any level not just enterprise systems. As a Software Engineer/Developer you should strive for doing things right and in the best way that you can. It is your responsibility to yourself, to your peers and your organization. If you can't be bothered or just simply don't care then you won't just be hurting yourself.

 

I've already looked into the Entity Framework and code first and all that other stuff. FOR SEVEN FREAKING MONTHS NOW and I'm no closer to understanding how it works.

 

That's unfortunate indeed. Perhaps you have simply had some bad resources or perhaps this industry really isn't for you and you must shortly ask yourself that question. Let me ask you though: What's driving you? Do you really even enjoy this kind of pursuit?