Real POCO`s in LightSpeed

Hello,

quote:"...entity classes derive from Entity<T>..."

Are there any plans when my entities can be used in a pure POCO style? EF4 can do it.

Why can LightSpeed not do it? I do not want to make my entities depend on a 3rd party tool.

Hi,

LightSpeed does not support POCO's. No we dont have any plans around this. Entity<T> provides functional concerns such as data binding, validation and change tracking which is of high value to most of our users and having richer entities is part of the design of LightSpeed. Our goal is to build a product that means you do less work and deliver solutions faster rather than rummaging around looking for T4 templates that might start adding support for things you get out of the box with LightSpeed.

We're not particularly in any race with what the EF supports because, frankly, they do a poor job supporting most things (Want Enums? Go find some hack work around that somebody found. Want multi-diagrams? Want built in SQL logging without needing 200+ lines of code? The list goes on). POCO support is one of the few things that EF does provide and even then we've heard some pretty horrible stories about working with the POCO generator. We love EF because we get so many unhappy EF users looking for a better solution :-)

Now, having said all that and sounding very Ivory Tower about it all... :-)

You could use your own base class that inheriets off Entity<T>. This way if you ever want to move off LightSpeed then you should be able to do so without too much fuss.

LightSpeed 4 will include a method on the UnitOfWork which can take an object and map it into a entity. This isn't POCO's, but to aid in our distributed entities strategy we saw it was useful to be able to map POCO's into entities. 

Even if you wrap your data access in a Repository pattern to hide away context etc, you're making an investment in a 3rd Party Tool - be it LightSpeed or EF. There's certainly religious debate going on regarding POCO's however we're not in the game of supporting scenarios that less than 1% of developers ever encounter (swapping our a data access framework to another on in a completed project).

So short answer - No POCO's. 

I hope that helps,

John-Daniel Trask

"... Entity<T> provides functional concerns such as data binding, validation and change tracking..."

data binding and validation is for me a UI concern therefore using a UI design pattern like MVVM my

ViewModel implements INotifyPropertyChanged and IDataErrorInfo. Above all the .NET framework

already supports that throught both Interfaces, why reinvent it ?

Change Tracking I do not need running an sqlite single threaded application.

Can you tell me where do you think you are better than the free Subsonic ORM e.g. for SQLite ?

We didn't re-invent it, we implemented all of those interfaces and more for you so that you're not writing them yourself. MVVM is certainly a nice way of working - often in more simple apps people expose their domain objects directly via the ViewModel as it does save a lot of code writing and we provide a lot of the infrastructure around binding and validation :-) This obviously depends on your application needs though.

SubSonic is more of a code generator than an ORM and has a fairly limited LINQ provider. If you prefer code generation then it's certainly an option, however the impression that I personally have is that it was a better product before the latest version (when they tried to add LINQ support to the ORM component). I also haven't checked recently but last time I looked there were a lot of people asking if the project was dead as there was no forum posts being written and almost no commits being made to the source repository (to be clear- this was some time ago that I last checked it out so please investigate further if you're seriously considering SubSonic as I may be wrong now).

You might not need change tracking, but you might want the validation, or you might want the entity state, or you might want the life cycle events, or you might like IBindingList implementations done for you on collections. The list goes on. You might not need certain aspects, but we know most users generally appreciate not having to write those things themselves when they do need them. 

If you're already going to all the work of mapping your POCO entity classes into View Model objects then I don't see any additional downside to mapping from an object that implements Entity<T> to your ViewModel.

I hope that helps,

John-Daniel