Looking for Sample Code

[omidkrad]

Hi, do you have sample code using features in your project?

Thanks!

[huyrua]

Hi omidkrad,

There is unit test in the sourcecode that you can look and see how things work.

Thanks.

[omidkrad]

Great. I'll check it out.

BTW, I was curious to know if you agree/disagree with this article. I particularly don't have much opinion on the subject, just reading about people's experiences and investigating a good approach to use.

Thanks.

[huyrua]

Hi Omid,

My answer is... it depends, which means neither agree nor disagree :)

The time I wrote this, my intention was to implement a Reporitory design pattern that was introduced in Domain Driven Design (DDD) where repository is one of its building blocks.

When DDD becomes popular, people started to look into it seriously to evaluate the advantages and disavantages. In case of repository, beside good comments and adoption, bad ones have been also given. Some also promoted new trends: CQRS

All of the evaluation, suggestion for improvement or even discard the repository are good depending on context. My opinions for this are:

"If you/your team want to apply DDD strictly, then repository should be implemented. If you don't, reporitory might still be your choice if you want to decouple the data access code with the actual ORM framework to 1) change an ORM framework later?!?, e.g. from NHibernate to EntityFramework and vise versa and 2) you want to ease unit testing (repository is just an interface so you will easily mock it in your test code)"

Things you might want to consider when decicing whether to apply this framework to your code:

• Do not use it if unit testing (or TDD) is not too critical (e.g. you don't want to write test code) OR you won't ever change the actual ORM framework. You dont need to abstract an ORM framework with a repository, just use NHibernate's Session or EntityFramework's DbContext/ObjectContext directly in your controllers, view models or services
• If you still want to use this framework, you should decide whether to use Code First or Database First approach: 1) if the database is a legacy one, you should choose database first development by generating the DbContext from Visual Studio and inject it to the repository 2) if the database is new but the number of tables (or entities) is large, e.g. more than 50 tables then you might not want to write too much mapping code but use database first approach instead 3) use Code First approach if the two options are ...false.

It's just some of my opinons, hope it helps.

[omidkrad]

Thanks Huy for your answer. We do Database First using Microsoft SQL Server Data Tools for Visual Studio and we've found it to work best for us. We're looking to improve our repository implementation to minimize database queries and run faster. I think your project is a good candidate. Do you know if it's used in any large application?

[huyrua]

Since reporitory is just a very thin layer (a wrapper) over an actual ORM, so using the repository is mostly same as you're using the Entity Framework 'directly'. So the answer for your question is: if Entity Framework is ever used in large application, so this repository :)

I used to use it in some applications I built, one of it is http://www.persify.com/. There are also many issues araised with performance, lazily loading, n+1 problem, etc. but I think the solutions are available out there in the internet with a quick googling, e.g. Entity Framwork now supports executing stored procedure to speed up/cache the queries from database side, so we just need to extend the repository with some method like: public IQueryable Get(string storedProcedureName, Dictionary<string, string> paramValues). It now also supports a feature like database migration which is one of the best practices in software development...