Vibrant discussion about CSLA .NET and using the framework to build great business applications.
Hi,
At my new job we're using the respository pattern to remove the data access code from the BOs. I have some reservations about this, namely that some business logic is now in the respository implemention when it really (IMO) should be in the BO. Such things as closing an order when an invoice is saved with certain values.
Also, does the repository pattern fit with Csla? I haven't checked out the ObjectFactory stuff, would it fit there? Is OF an implementation of repository?
Or is repository the new Pattern of the Week?
Thanks for any insights!
The repository pattern is a solid pattern, and is widely used. Like any pattern, it should only be used if it solves a problem you have.
The repository pattern solves the problem of switching between different data access providers without switching the calling code. It is very closely related to the broader provider pattern concept, and a provider pattern is one way of implementing a repository pattern.
So if you need to switch DAL implementations, the repository pattern is a good tool to achieve that end.
CSLA supports four data access models - I describe them in Chapter 18, and more thoroughly in the Core 3.8 video series:
Options 2 and 4 work very well with the repository pattern.
Option 3 already implements a repository pattern.
Options 3 and 4 require the most work, because the object factory models require that you manage all the business object metastate. Options 1 and 2 are easier, because the data portal manages the metastate for your automatically.
Rocky
Rocky,
Thanks for the answer. That's pretty much where I would expect repository to fit. It seems that many proponents of the pattern though advocate the UI directly invoking the repositories, which I'm not sure is the best route to go. Many examples also show anemic models as well, and dismiss smart BOs.
Continuing this, it seems that options 2 - 4 also open up the ability to mock the repository / DAL, so that you can unit test Csla BOs without actually needing a database. Is that a fair statement as well?
Thanks
PS - Blake, I'd appreciate the chance to mark my own question answered. If I don't do so in a few days thats one thing, but I didn't even get 24 hours to do so.
Yes, options 2-4 allow for a pluggable DAL, regardless of which pattern you use to achieve that goal (repository, DI, etc).