Create repository pattern

[andersburla]

Trying to use SqlFu as my ORM and want to make a repository using the repository pattern. But how would i create my generic repository where I have a public IEnumerable Select() - should select all items for that entity.

I would write something like db.Query( "SELECT * FROM ...") - how do I get access to the TableAttribute that I used for my class and add it to my select command?

Kind regards Anders

[sapiens]

I'm using SqlFu for a blog engine I'm developing, inside the repository. I'm considering the generic repository an anti pattern (http://www.sapiensworks.com/blog/post/2012/03/05/The-Generic-Repository-Is-An-Anti-Pattern.aspx) so I don't recommend using it.

If you really want it, then the repository is pretty much a wrapper around SqlFu. And you can use the db.Get() method to retrieve one entity. You can implement a generic repository in several ways and I think it doesn't matter the (micro-)ORM used, basically it's still a facade wrapped around the ORM. You don't need to access TableInfo, you can use the public functionality without a problem (Get and (Paged)Query are all that you need).

[andersburla]

I have looked at most of your blog posts about DDD, ORM and the repository pattern. Could you try and explain how your would structure your code for lets say the Blog post example you have talked about in the blog post. Would this be the structure you have using SqlFu as the ORM.

Project.Persistence

• Post - this has the ORM mapping used by SqlFu

Project.Framework

• Repositories
  • IPostRepository
  • PostRepository
• Post - Domain object
  • GetAll() //These methods uses db.Query and gets a DB Post and copies the data to a business object and returns it
  • Select()

Project.Website - website project that uses the framework to get business objects to get data and save it

Does this makes sense and is it the right way to structure it for a case like that?

[sapiens]

Since I prefer a DDD approach, I wouldn't structure the project like that. The Repository implementation should stay in the Persistence layer and the Domain should not know about the Persistence at all (i.e GetAll and Select are not part of it, they are Repository concerns).

As a practical example, you can check the Fulldot blog engine (very much work in progress) https://bitbucket.org/sapiensworks/fulldot/src/02ed13029443/src/Fulldot.Infrastructure.Storage .

[andersburla]

Okay I see . was also my plan to do it. But if you have the repositories and the GetAll, Select etc. methods at the repositories and in the Persistence project how will you save the post?

Let say you have the Project.Website . which projects should it reference - of course domain - but should it also know about persistence to be able to save the entity when its created/edited on the website?

[sapiens]

The Project.Website is also the web app itself and the place where you setup the DI Container so it will reference all the projects involved. However, the other projects will reference only the projects they need. The Domain doesn't depend on anything, but Persistence may depend on the Domain (or a project containing the required interfaces) and on Infrastructure for example.

For view models which can be used by repositories, I've created a ViewModels project, so that Persistence shouldn't depend on the asp.net mvc app. It's not hard, but it's quite confusing until you have a clear understanding of what you want.

At least in Fulldot, every controller sends a command to a command handler which will use a repository to save the entities. Basically, the Controller is not using directly a domain repository (it uses a query repository though), so the Web project has no real dependency on the Persistence. But because the Web project hosts the app start up and handles the config of the DI Container, it references the Persistence. If I'd do the Container setup in another project, then the Web project wouldn't know about Persistence.

[andersburla]

But in my case I want to have an API/Framework dll that people can use for to crazy stuff :) Let me try and explain in a little more details how I have though of the structure up until now and what I want the different projects to be. The hard part at the moment is how to do the right project structure and which projects should have references - so you advice is much appreciated! Especial about where to place the data models, the domain models, the repositories etc.

Project.Persistence - should do the save to DB Project.Framework - should give other developers access to our domain and use it in their own projects Project.API - this will do security checks and make some abstractions of the Framework Project.API.REST - this is a REST API that maps the requests and uses the API project Project.API.Umbraco - much like the REST API - this is just a "hardcoded" API for simple use in Umbraco - uses the API project - just like the REST API project.

Hope it makes sense - else you can reach me at skype - same user name as here

[sapiens]

We'll continue this discussion by email.