[AccessD] LightSwitch (was: Automating web page entry (was:Scrollbutton))

Shamil Salakhetdinov shamil at smsconsulting.spb.ru
Sun Sep 12 04:44:57 CDT 2010


Hi Gustav --

Thank you for your reply.
No, I didn't expect quick feedback on my questions.
I have just put them here to mark what I'd like to see available in
LightSwitch to consider it as a "serious" development tool.

I have read somewhere that the next Beta of LightSwitch should have MS
Access databases available as datasources? Via EF? That would be really
useful if they implement something like EF provider for MS Access
databases...

POCO article - yes, looks interesting but too complicated IMO. I didn't yet
check how POCO ORM is done in VS2010 EF but as far as I have got known it's
done there smoothly with most of infrastructure/plumbing ORM code "buried"
in EF and related classlibs - is it right? ...

Thank you.

-- Shamil

 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Sunday, September 12, 2010 12:53 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] LightSwitch (was: Automating web page entry
(was:Scrollbutton))

Hi Shamil

I feel that what you are asking for here is beyond the scope of LightSwitch.
POCO and unit testing seem not to be incorporated or considered.
By the way, I located a good explanation on POCO (Plain Old CLR Object)
here:
http://blogs.msdn.com/b/jkowalski/archive/2008/09/09/persistence-ignorance-p
oco-adapter-for-entity-framework-v1.aspx 

Please read my post to JC about the data storage.
I can't answer your other questions - I'm still working my way through the
tutorials in my little spare-time ... so later maybe!

/gustav 


>>> shamil at smsconsulting.spb.ru 12-09-2010 00:37 >>>
Hi Gustav --

Thank you for your additional notes.

What about "Model First" approach?
Does VSLS allows to use it in this Beta version?
I mean to define my business conceptual model as a set of POCOs?
A set of POCOs with some sample/test data hardcoded/stored in/loaded from
plain text/delimited/xml/... files to not be "bound to" any real DBMS while
working on prototype UI and business models?
And to generate later database model from some of the classes of my POCOs
set?
Is it possible in this VSLS Beta version to keep/move all your object layer
POCOs in a (set of) class library(-ies)?
As far as I have got from VSLive presentation VSLS interacts with (EF and
WCF RIA in this Beta version?) object layer via <IQueryable> (and
obviously(?) uses .NET Reflection to get information on object layer types
etc.)

I'm not sure how then CUD operations are supported/implemented? What .NET
Framework interface is used for that? Or VSLS has got defined its own .NET
interface/API/.NET Attributes? 
They should be intensively using .NET Attribites to keep meta-information,
do they? Or they use special xml you mentioned to keep/interpret all
meta-information even on run-time?

<<<
Most data is collected in a local lsml (LightSwitchML) file but it connects
via the EF to nearly everything just like that. It is so flexible, and
validation, error messages and so on is ready at hand with zero or extremely
little code. Importantly, the EF let's you "remodel" any data source making
it very easy to adapt and connect/relate different data sources - again with
zero code; this feature alone is worth studying.
>>>
As one can guess (based on how MS usually designs development frameworks in
VS on top of .NET Framework) lsml meta-description is used on design time,
and it's used also to generate real C#/VB.NET code keeping/interpreting all
the (non generated into code) meta-information on runtime in attributes.
Yes, that should be it...

What base level VS project type lies under VSLS project - an MS SilverLight
front-end project?

Thank you.

-- Shamil

<<< snip >>>




More information about the AccessD mailing list