What is different between CQRS and CRUD and can I use the UnitOfWork and Repository patterns in both cases ?
If I have a complicated relationship between the entites which one you are recommending me and why ?
CQRS pattern : http://martinfowler.com/bliki/CQRS.html
CRUD : http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
Any help will be greatly appreciated.
CQRS is usually used for complex application projects. DDD is also used for complex application projects and seems to be associated with CQRS.
DDD attempts to deal with the complexity of the behaviour. CRUD systems have little or no behaviour. A system with little or no behaviour doesn't really have a complex event structure, so it's hard to say how much benefit you get from CQRS.
CRUD - you perform reading and writing operations on one object.
CQRS - you split reading and writing operations into two separate objects. You can simplify it, and implement it as two separate interfaces on one object: one for reading, and one for writing. Then you can instantiate objects depending on what do you need it for. Or you can move it even further, and use separate databases for reading and writing.
For most cases CRUD is the answer, but CQRS can be applicable in some complex scenarios.
If you are using Entity Framework, you shouldn't use Unit of Work and Repository, because it's natively implemented by EF.
In CRUD, using Unit of Work and Repository is normal. For CQRS - I have no knowledge.
Related
I understand that at least EF 6 supports multiple DbContexts. This can be used to model BoundedContext. I did some google searches but could not find a definitive answer to this question. Is it advisable to use different db schemas for different DbContexts/BoundedContext? I know that ORMs abstract away the persistence mechanisms but I personally can see parallels between shemas and ddd/ef contexts.
It is a possibility. As with most architectural questions, the answer is: it depends.
In this case, it depends on how your overall architecture is and how your bounded contexts are structured. If they have similar aggregates that are persisted to the same tables (that is, they're different because of the context), it might be a good idea to have different DbContexts because then you can evolve them separately.
Note though that you may be introducing hidden constraints and dependencies between your bounded contexts.
If your bounded contexts have very different aggregates, then there's no need to use different DbContexts and you can just share the same one.
Another option you might consider, is using a different DbContext for reading and writing. It also allows you to evolve your model separately. (that's more of a CQRS approach though)
From reading various books and articles, I seem to rather often find the usage of the Repository-pattern suggested. I get the point if you need to be able to swap out your data layer from one to another, but my question is, if I know with 100% certainty that I will not use any other tech for data access, is there any reason for using said pattern?
The thing that I find myself doubting the most is that I don't really see what this extra layer of abstraction can bring to the table in this scenario. From my experience, EF with its fluent linq-to-entities -functionality should be more than enough for pretty much all my needs.
The most usual cases seem to start the repositories with methods such as FindAll, Find, Add and Delete, all of which are very easily accessible directly through EF (so no code duplication to speak of).
So am I just missing some big point, or is the repository more for when you need to support multiple different data access technologies?
They are many opinions on the issue but after using repositories for 2 projects, i never tried it again.
Too much pain with hundreds of methods for all those cases with no clear benefits (i'm almost never going to swap out EF for another ORM).
The best advice would be to try it out so you can make an informed opinion on which route to take.
Some opinions against it here
I think you're on the right direction. I asked myself the same question two years ago after I've used the repository pattern in some projects. I came to the conclusion that hiding your ORM behind a repository implemented on top of your ORM will get you nothing but unnecessary work. In addition to implementing meaningless FindAll, Find, Add ... methods you would loose some performance optimization possibilities that the ORM gives you. Or at least it will get quite hard to apply some of those methods.
So if you're not going to switch your ORM within the lifetime of your project, I don't see any benefits in applying the repository pattern.
So instead of preparing for the situation where one could in future easily switch the ORM, I would suggest to do some more investigation upfront, wisely choose an ORM, stick with it and stay away from the repository pattern.
What people don't realize is that EF is already a Repository and a Unit-of-Work.
Repository has recently become an anti-pattern. Never use a design pattern because its cool or trendy or trying to build your resume, in fact this should be a standard rule for all design patterns.
Only build a Repository and Unit-of-Work on top of EF if your application is
very large (lasagna layer)
long-lived (10 years or so)
has more than 5 developers working in parallel
has developers that are separated geographically
requires a lot of maintenance
multiple data access infrastructures
A good indication is when upgrading from EF5 to EF6 requires you to knock on everybody's door.
I'm not as hot on the repository pattern as I used to be, but I still find it can be useful in the following scenarios (assuming swapping the ORM isn't one of them):
Unit testing (assuming you'd rather mock or stub than use Sqlite or hit a real db)
Being able to stub out data access during development via a repository that has an in-memory IEnumerable as its backing source.
I am actually in disagreement that EF is a correct example of a "Repository Pattern". It is a typed Data Access Layer and an exposed LINQ implementation.
Please note that if one fully endorses EF as "the business domain" then the above does not hold; however, I use EF - as poorly as it does - with Schema First, in which EF is not the strict business domain. The term "correct" is used to reinforce this viewpoint - adjust for your own perspective / design.
A correct Repository Pattern, in my book, exposes aggregate roots of relevant operations. That is, the implementation details (EF) is kept within the Repository, as much as possible. That is, the Repository takes care of the mapping of the relevant Domain objects to the underlying model.
This is an agreement with how Microsoft defines The Repository Pattern - note that the business entities are mapped to a data source. (And thus my fundamental disagreement with EF fulfilling this role: EF only has a chance of sanely maps business entities when designed from Code First.)
The best summation / article I have found is Repository pattern, done right by Gauffin. While he approaches the Repository pattern from a more extreme view than I, here are some key points as to why EF's simply bleeds through an Active Record / ORM pattern.
Here are some selected excerpts that highlight why I do not thing that EF is a proper implementation of a Repository Pattern.
The repository pattern is an abstraction. It’s purpose is to reduce complexity and make the rest of the code persistent ignorant. As a bonus it allows you to write unit tests instead of integration tests. The problem is that many developers fail to understand the patterns purpose - and create repositories [ie. EF] which leak persistence specific information up to the caller
..
Using repositories is not about being able to switch persistence technology (i.e. changing database or using a web service etc instead) .. Repository pattern do allow you to do that, but it’s not the main purpose.
..
When people talks about Repository pattern and unit tests they are not saying that the pattern allows you to use unit tests for the data access layer .. If you use ORM/LINQ in your business logic you can never be sure why the tests fail.
..
Do note that the repository pattern is only useful if you have POCOs which are mapped using code first. Otherwise you’ll just break the abstraction using the entities. [That is, only EF Code First can even attempt to meet this requirement.]
..
Building a correct repository implementation is very easy. In fact, you only have to follow a single rule: Do not add anything into the repository class until the very moment that you need it
And if you do use EF as a Repository - I believe it's still a typed DAL, as much as it bleeds - please do not try to hide it in a "more generic" pattern - a Repository pattern is not about type unification, it is about exposing aggregate roots for a particular context and operations on such.
See What specific issue does the repository pattern solve? as well.
While I speek against EF being a correct Repository Pattern - it is the Active Record pattern - I am not a Repository purist. That is there are cases when I will bleed EF (or L2S) entities in specific cases; I accept this as technical debt. Just understand the cost of breaking such a Repository / Domain boundary.
I have been reading about Command Query Responsibility Segregation (CQRS) and how this pattern would suit our current applications.
When it comes to the read model I am well aware of the concepts:
"separating read and write data model", "flat denormalized data returned by the thin read layer". In most cases we are stuck with the same database(the same read/write data model), running on SQL Server with normalized tables, with common layered application on top of it.
So, is it any value of applying CQRS on this kind of scenario?
If so, what would it be when it comes to the read model side?
Another question that hits my mind is MVC application requesting information from my thin read layer that expose flattened out views. Data exposed still need to be structured(aggragated) before presented to the user, or am I wrong?
Best regards
CQRS doesn't need to have a flattened read model; that is a benefit that CQRS can allow you to provide, but it is neither required nor a key part of the approach.
CQRS is about separation (or segregation if you follow the name). It is the Command Query Separation principle on steroid (in my opinion). The benefits that it provides you (off the top of my head) are:
separation of your read operations from your write operations;
communication between layers via messaging (e.g. commands, events), so that your layers are clean;
separation within your layers, applying the Single Responsibility Principle (e.g. your domain applies business logic, your command handles route commands, your denormalizers or event handlers (or whatever you call them) persist information to your read store, etc.)
allows you to have team members work on different parts of your application without hard dependencies between them;
etc.
So if those things above are important to you or something you want to strive for (and your application's design supports implementing CQRS), then CQRS provides benefit and value to you.
There are many benefits to CQRS. It's not the right solution for every problem, but when the stars align, it's a nice approach to your problem (even if you don't have a denormalized read store, or an event store, or an async model, etc.).
I hope this helps!
I've fought with multiple joins so many times in my career that when a structure like CQRS and ES comes along and offers a clean way to simplify the read side, I jumped at it. The nice thing is that you can get many of the benefits without necessarily implementing all the elements often associated with CQRS and ES. Just separating command from queries has the benefit of simplifying your code. However, when you do start using a de-normaliser to build out read models for you application you suddenly realise how simple, clean and performant your app can be.
If it helps to see 'how' this de-normalisation works take a look at this post (it comes with a code sample to take a gander at): How to build a master details view with CQRS and ES. I hope you find this helpful.
Applying CQRS over the same (say) third normal form database can still give you value on the read side if it allows you to stop projecting read models from domain objects.
This also allows you to better specialise your domain to (I assume) transaction processing, meaning many relationships may not be necessary.
Let's say I have an app that should ideally be able to use a relational database, object database, XML files, or whatever to persist its data. In the spirit of coding to interfaces instead of implementations, I have a generic DataStore interface that specifies a contract for all I/O involving the data store. This interface can be implemented by concrete classes such as RDBMSDataStore, OODBMSDataStore, XMLFileDataStore, and so on.
This works well as long as I keep the contents of the DataStore interface simple - i.e. getThis(), getThose(), saveThat(), updateThis(), etc. But as soon as I require more complicated queries, it breaks down. The XMLFileDataStore class obviously doesn't understand SQL, and the RDBMSDataStore class obviously doesn't understand XPath/XQuery. And OODBMSDataStore understands something entirely different depending on the OODBMS in use.
I could adopt a language-independent object query language, write all my queries in that and then have the concrete classes translate them into their native language, but that's a huge task, if I want to be complete.
Are there standards or best practices for handling this kind of situation in Java? Unfortunately it seems like 99% of the world interprets "database independence" to mean "relational database independence" and ignores the object databases, XML databases, document databases, etc. entirely.
From the way I read the question, this sounds a lot like the semantic that Hibernate brings to the table for Java. It even has mode for dealing with XML as the content backing store (using Dom4J). The Hibernate API has a number of extension points that could allow the addition of an OODBMS model. Even if Hibernate turns out not to be the best solution for you (implementation-wise), I think it provides a good example of the types of patterns that can be used to solve the problems you proposed.
I’m currently working on a prototype of a medium size web application, and I thought that it would be good to also experiment with Entity Framework. The problem is that the major part of the application is not the data layer and logic, and so that I don't have much time to play with Entity Framework. On the other hand, the database schema is quite simple.
One of the problems I’m facing is that I cannot find a consistent way to "write queries". As far as I can tell, there are four "interfaces" for the job:
LINQ to Entities
LINQ to Entities using LINQ extension methods
Entity SQL
Query builder
OK, the first two are essentially the same, but it’s good to use just one for maintenance and consistency.
I’m mostly puzzled by the fact that none of them seems to be complete and the most general. I often find myself cornered and using some ugly looking combination of several of them. My guess is that Entity SQL is the most general one, but writing queries using strings feels like a step back. The main reason I’m experimenting with something like Entity Framework is that I like the compile time checking.
Some other random thought / issues:
I often also use the ObjectQuery.Include() method, but again it takes a string. Is this the only way?
When to use ObjectQuery.Execute() (vs. ToList())? Does it actually execute the query?
Should execute queries as soon as possible (e.g. using ToList()) or should I not care just let leave the execution for the first enumeration which gets in the way?
Are ObjectQuery.Skip() and ObjectQuery.Take() available only as extension methods? Is there a better way to do paging? It’s 2009 and almost every web application deals with paging.
Overall, I understand there are many difficulties when implementing an ORM, and often one has to compromise. On the other hand, the direct database access (e.g. ADO.NET) is plain and simple and has well defined interface (tabular results, data readers), so all code - no matter who and when writes it - is consistent. I don’t want to faced with too many choices whenever writing a database query. It’s too tedious and more than likely different developers will come up with different ways.
What are your rules of thumbs?
I use LINQ-to-Entities as much as possible. I also try and formalise to the lambda-form, as opposed to the extended SQL-style syntax. I have to admit to have had problems enforcing relationships and making compromises on efficiency just to expedite my coding of our application (eg. Master->Child tables may need to be manually loaded) but all in all, EF is a good product.
I do use EF's .Include() method for lazy-loading, which as you say, does require a string input. I find no problem with this, other than that of identifying the string to use which is relatively simple. I guess if you're keen on compile-time checking of such relations, a model similar to: Parent.GetChildren() might be more appropriate.
My application does require some "dynamic" queries to be performed, though. I have two ways of meeting this:
a) I create a mediator object, eg. ClientSearchMediator, which "knows" how to search for clients by name, etc. I can then put this through a SearchHandler.Search(ISearchMediator[] mediators) call (for example). This can be used to target specific data structures and sort results accordingly using LINQ-to-Entities.
b) For a looser experience, possibly as a result of a user designing their own query (using high level tools our application provides), eSQL is ideal for this purpose. It can be made to be injection-safe.
I don't have enough knowledge to address all of this, but I'll at least take a few stabs.
I don't know why you think ADO.NET is more consistent than Entity Framework. There are many different ways to use ADO.NET and I've definitely seen inconsistency within a single code base.
Entity Framework is currently a 1.0 release and it suffers from many 1.0 type problems (incomplete & inconsistent API, missing features, etc.).
In regards to Include, I assume you are referring to eager loading. Multiple people (outside of Microsoft) have developed solutions for getting "type safe" includes (try googling something like: Entity Framework ObjectQueryExtension Include). That said, Include is more of a hint than anything. You can't force eager loading and you have to always remember to call the IsLoaded() method to see if your request was fulfilled. As far as I know, the way "Include" works is not changing at all in the next version of Entity Framework (4.0 - to ship with VS 2010).
As far as executing the Linq query as soon as it's built vs. the last possible moment, that decision is situational. Personally, I would probably execute it as soon as it's built for the most part unless there was a compelling reason not to, but I can see other people going the opposite direction.
There are more mature ORMs on the market and Entity Framework isn't necessarily your best option. For the most part, you can bend Entity Framework to your will, but you may end up rolling your own implementation of features that come out of the box with other ORMs.