Xamarin SQLite.Net PCL -- what is good option to keep domain model free of sqlite attributes?

3
votes

I'm starting out with Xamarin and sqlite, specifically this package:

https://github.com/oysteinkrog/SQLite.Net-PCL

There is no fluent api (IE like in Entity Framework), which is OK, but instead, does anyone have a pattern to keep the attributes, such as [PrimaryKey] out of the domain model so that my domain library doesn't need a reference to the sqlite libraries? The only way I can see is to create separate classes in my sqlite repo library for each of my domain classes, and employ some kind of mapping scheme. But that seems a lot of work just to avoid an attribute. In fact, in this case it's probably easier just to bang out the sql and do it that way instead of using SQLite.Net-PCL's built-in ORM.

It's probably worth it in my case to just litter my domain with the attributes and create a dependency on the SQLite.Net-PCL library.

Are there any other libraries that i can use with xamarin/PCL that might help? Or is there a better technique?

1
c#sqlitexamarindomain-driven-designsqlite-net

1 Answers

1
votes

If there really is no configuration-based approach like the fluent API you mention (I don't know of one), you have two options:

Use a separate persistence model

This is usually not as much effort as it initially appears, and it provides real separation of concerns. By going down this path, you also have a natural location for schema migration logic and custom data mappings.

The ugly part of this is the mapping between the persistence and the domain model, which can typically be solved elegantly by using an object to object mapper. For C#, a very good solution is AutoMapper.

Re-evaluate your decision to go with DDD

This is a rather drastic change, but given the fact that you're going to build a mobile app, there is a chance that DDD is a bit heavy anyway. If that's the case*, the door is open to just make the trade-off and have a unified persistence and "domain" model.

*: Take this decision seriously and consider all requirements. Don't base your decision solely on the "implementation detail" problem that you're having right now.