This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi all, First, let me admit I'm a newbie when it comes to the Repository Pattern and Lightspeed. I'm trying to build my first MVC application using a class model clearly separated model from the underlying mechanism of persistence. My problem: Lightspeed clearly expects the class model to be an intrinsic component of the assembly that performs the actual data access, meaning it would be difficult to de-couple Lightspeed from the architecture someday when the 'next great storage methodology' becomes available. As a result, it seems impossible to cleanly implement the Repository pattern using Lightspeed. Can anyone tell me if my supposition is correct? Best, David |
|
|
|
|
Hi David, I will assume you are abstracting your repositories via a set of interfaces - e.g. ICustomerRepository rather than say specifically using the LightSpeed Context or UnitOfWork classes and you are dealing in terms of entities through the layer - e.g. a class based on Entity<T>. Given this set-up you will have a couple of places you are using LightSpeed specific code 1. In the concrete implementation of your repositories, however these are nicely abstracted so swapping in a replacement implementation should be no problem 2. In some kind of setup code (e.g. Global.asax) or a DI container module to initialize LightSpeed and perhaps maintain a per request scoped unit of work or the like. This is plumbing and would simply be replaced by the equivilant for any replacement framework/approach. 3. Any specific functionality you are leveraging from Entity<T> such as the validation functionality in LightSpeed (e.g. .IsValid and .Errors properties). 4. If you are returning IQueryable sets up from your repositories to allow for deferred execution and are leveraging our LINQ provider, then specific queries may or may not be supported by another LINQ provider, or you may be falling back on LINQ to Objects if the replacement approach does not natively provider a LINQ provider - however I imagine this would be one of your primary concerns in any migration if you were designing this way. So generally we would not expect this to be much of a problem from an architectural POV. How does this match up with your current thinking on this?
Jeremy |
|
|
|
