bpdconnectteam/BPD-Connect — comment on commit 5c63295874c2aa2e1b30928eb9493047201ff875
File:  line 0
By Manas-jog:

# Notes on commit made

## Previous project structure

Its quite obvious. All you had to do w.r.t this structure was to straightaway start coding, followed by debugging. Modularity was there, but not organized still.

## New project version

NOTE: bcdatabase and bcdatabaseschema are same, and nothing has been changed in that.

This project uses layered type architecture. The following is the break up:

### Overall break up:

BPDConnect.Web(contains web ui)
|
|
BPDConnect.WCF(interface for service)
|
|
BPDConnect.Domain(provides all application logic)
|
|
BPDConnect.Repository(acts as an interface for underlying database)
|
|
ADO.NET entity framework(does object-relation mapping, data validation, etc.)
|
|
Any database or collection of databases.

### Detailed break up(see soln file in vs2011)

*DataTier : (it contains the data model, as well as the application logic)*

Consider a situation where the BPD-connect site needs to be expanded to various platforms(like iphone, windows or mac). Now, there are 2 ways to deal with this situation. Either code the entire application logic as well as user interface and communicate with the bpdcdatabase lying in some server. Or, you can communicate with the DataTier which contains both the logic as well as database, and just code the user interface. Obviously, 2nd choice is preferred.

This datatier uses WCF to communicate with app running on any platform.

This datatier is further divided into:

* BPDConnect.Domain : All logic related to our application lies here.

* BPDConnect.Model : Uses ADO.NET Entity Framework 4.2. Now why entity and not linq2sql? Well, except for minor performance degradation, entity allows us to use not just MS SQL Server, but any server! MySQL, etc. all are allowed. Also, many to many relationship can be dealt here in a natural and obvious way, which will go a long way in reducing application logic complexity. Not just that, when you delete an entity from database, all entities 'dependent' on this entity are automatically deleted. Finally, linq2sql support is gone, and linq2entities is here. However, because L2Entities is not complete, we will be using Linq-to-objects here.
This project includes models coded into classes. Also all basic database validation can be implemented right here in form of attributes, instead of custom functions.

* BPDConnect.Repository: Contains files which implement the IRepository interface. This IRepository interface aims to separate application logic with the database, which aids in coding application logic. It also allows us to:
1. Discard entity framework, or use multiple databases without changing a single piece of application logic.
2. Test the application logic(Most important)

* BPDConnect.WCF : This contains WCF service interface.

* BPDConnect.WCFHost : This is optional. Its main use is to run as console application which acts as a host for the datatier service. You may use IIS server to host, and hence delete this project. However if you want to debug better, use this.

*Library*

This contains logic(not application logic) common for all layers. For example function to convert string to md5 hash or classes which contain social graph implementation, etc.

*Unit Tests*

Note: BPDConnect.Domain.Test needs to be inside this, and this folder needs to be renamed to "tests".

This group of project allows us to test all aspects of our application. Instead of going the noob way of debugging(which takes forever to start) and then recreating situation to a point where we expect a bug to occur, we will create list of functions that do automate all this. These testing functions can then be run automatically every time you perform a test, and tell you whether all components are working. Also, we can use these to test the performance of all components.

Now there are 2 types of tests, one which just tests the logic of component : unit tests, and ones which test component actually : integration test.

Now, even if at this point you have doubts on why we need testing, here are 2 situations which will occur every time:

"A BPDConnect team member notices that a particular function does not cover all its purposes. This guy will either be a good guy greg and call that person, or he will change the function code itself. Now after few days, our team realizes that a particular part of our project is not working as intended. As it turns out, when this 'good guy greg' changed that defective piece of code, he ignored other situations which the original creator knew, and hence this code remained defective"

"Suppose one of us changes a piece of code which is indirectly related to another piece of code. Also suppose this indirect change leads to logic error in a random function of application. Now how the hell do you track it?"

This is why we need unit tests and integration test.

Lastly, this structure allows us to add new features very easily : Just add a table in database, map it and create class for it in BPDConnect.Model, code logic for this in BPDConnect.Domain, verify if its working in BPDConnect.Domain.Test, check its performance there itself, and also provide user interface in BPDConnect.Web to access it, and that's it. Done, nothing broken, and component added. Flawless!

However, i have my doubts whether all this benefits will appear in long run or not. But, because this is a practice(actually applied practically) and not a methodology, i am quite confident of this model.

Now start commenting!