Question

I just need a little help how to organize my code. This is not philosophy but real problem. I am looking for a solution that works.For example in php and symfony framework it was crystal clear how to organize the code. In c# .net i feel lost.
I just want to rewrite from scratch my project reusing some parts.

Description
First of all as i am targeting many platforms windows mobile , windows desktop , android ,web it seems that i should expose functionality as web service instead of directly communicating with database. Is this correct ?
Then i need some client applications. A wpf one ,android and windows mobile.

In wpf i guess that i can use MVVM pattern.

Questions
I use postgresql with ADO.NET and performance is amazing compared to other similar applications. I found that Dapper would help a lot and was something that i was looking for. However i am having trouble where to put sql code. Ok i have model classes.. like Customer ,Oder etc… Then where should i put the sql code ? Should i put CRUD code at separate class ? Currently i have some code in controller classes but I construct a new controller class all the time when i want to something. And this doesnt seem really good.
Is there any pattern how to organise database code ?

Answer 1

You backend part need to provide following functionallity:

1. Operate with clients: process requests from client and sends responses back to client. The main issue here is to define request/response format. You may use SOAP or REST, for example, .NET framework service frameworks (like WCF) works with both that protocols, but as for me it is more SOAP oriented. WCF uses classes set to describe service contract, so I think it is better to work with some entities instead of pure ADO.NET

2. Notify clients about errors: includes validation errors and exceptions. Validation messages needs to be displayed on the client, usually by property names, exceptions should be processed also. Also there is problem with handling database-related errors and convert it to domain model errors.

3. WCF architecture based on services – it is contract and its implementation accessed by set of protocols. Since WCF uses entities serialization and deserialization it is not good idea as for me to put any business logic to entity. Put it to separate classes (repositories) and call repositories from your services. It is so called anemic domain model – domain entities does not contains any business logic – in opposite to rich domain model – entities contains business logic.

4. Access to database is usually encapsulated to set of classes called Data Access Layer (Or DAL). DAL provides a set of method required for persist entities to database or load entities from database. This method should contains no business logic but encapsulates database details and structure from business logic layer. To implement that layer helper tools often used: like ORM (Entity Framework, BLToolkit etc.).

5. Business logic layer (BLL) – uses methods from DAL to persists entities. It shouldn’t work with database directly – just call methods from DAL. Business logic contains all operations with entities and entity sets – including validation, calculation, permission checking and etc.

EDIT

To support transaction you may use decoupled from database classes like TransactionScope or transaction support built-in to ORM.

It is always good to have business logic relatively non depended on DAL operations – i.e. business layer process entities in way it doesn’t know about entities would be saved. If it is possible you may encapsulate database transactions inside DAL – but this may must you to have ugly methods with a lot of parameters and pass a lot of entities and collections to save inside transaction.

But usually it is not possible and business logic layer methods calls DAL operations few times – loads and saves additional entities. In this case transaction scopes or it ORM analogues is a good choice.