|
2 | 2 |
|
3 | 3 | # D3 ORM
|
4 | 4 |
|
5 |
| -D3 is golang ORM and DataMapper. This project was design with respect to such |
6 |
| -ORM's like hibernate and doctrine. Main task - give an instrument for create |
7 |
| -nice domain layer. If your business code not expressive enough, or if you want unit |
8 |
| -tests without a database, or if in your application, for some reason, you need aggregates, |
9 |
| -repositories, entities and value objects - d3 can be a good choice. |
| 5 | +D3 is a golang ORM and DataMapper. This project was designed with respect to such |
| 6 | +ORM's like hibernate and doctrine. The main task - give an instrument to create a nice domain layer. If your business code not expressive enough, or if you want unit tests without a database, or if in your application, for some reason, you need aggregates, |
| 7 | +repositories, entities, and value objects - d3 can be a good choice. |
10 | 8 |
|
11 | 9 | ## Motivation. Why another ORM?
|
12 | 10 |
|
13 |
| -In my opinion in GO have a lot of good ORM's. They are pretty fast and |
14 |
| -may save the developer from a lot of boilerplate code. But, if you want to write code |
| 11 | +In my opinion in GO have a lot of good ORM's. They are pretty fast and may save the developer from a lot of boilerplate code. But, if you want to write code |
15 | 12 | in DDD style (using DDD patterns and philosophy) it's not enough,
|
16 | 13 | because DDD approach imposes certain requirements. Main requirement -
|
17 |
| -persistence ignorance. Current GO ORM's do not provide sufficient level of abstraction for this. |
18 |
| -Other words, we need keep business logic free of data access code. That's why D3 created. |
| 14 | +persistence ignorance. Current GO ORM's do not provide a sufficient level of abstraction for this. |
| 15 | +In other words, we need to keep business logic free of data access code. That's why D3 created. |
19 | 16 |
|
20 | 17 | ## Main futures
|
21 | 18 |
|
22 | 19 | - code generation instead of reflection
|
23 |
| -- db schema auto generation |
24 |
| -- one-to-one, one-to-many and many-to-many relations |
| 20 | +- DB schema auto-generation |
| 21 | +- one-to-one, one-to-many, and many-to-many relations |
25 | 22 | - lazy and eager relation loading
|
26 | 23 | - query builder
|
27 | 24 | - relation fetch strategies (eager/lazy as above or extract relation in one query with join)
|
28 | 25 | - fetched entity cache (first level cache)
|
29 | 26 | - cascade remove and update of related entities
|
30 |
| -- application level transaction (UnitOfWork) |
31 |
| -- db transactions support |
32 |
| -- smart persist layer don't generate redundant queries on entity updates |
| 27 | +- application-level transaction (UnitOfWork) |
| 28 | +- DB transactions support |
| 29 | +- smart persist layer doesn't generate redundant queries on entity updates |
33 | 30 | - UUID support
|
34 | 31 |
|
35 | 32 | ## Documentation
|
36 | 33 |
|
37 |
| -All documentation is on project [wiki](https://github.com/godzie44/d3/wiki/Table-of-contents). |
| 34 | +All documentation is on the project [wiki](https://github.com/godzie44/d3/wiki). |
38 | 35 |
|
39 | 36 | ## Example of usage
|
40 | 37 |
|
41 |
| -Full example of usage you can see in [this](https://github.com/godzie44/last-wish) project. Note, that is it is a test project |
42 |
| -with main responsibility show d3 orm in action. |
| 38 | +A full example of usage you can see in [this](https://github.com/godzie44/last-wish) project. Note, that is it is a test project |
| 39 | +with main responsibility show d3 ORM in action. |
43 | 40 |
|
44 | 41 | ## Tests
|
45 | 42 |
|
46 |
| -D3 integration tests require a postgreSQL database. Connect to the database specified in the D3_PG_TEST_DB environment variable. |
| 43 | +D3 integration tests require a PostgreSQL database. Connect to the database specified in the D3_PG_TEST_DB environment variable. |
47 | 44 |
|
48 | 45 | ## Roadmap
|
49 | 46 |
|
|
0 commit comments