IndrajeetP wrote:
I am in the middle of evaluating LLBLGen as an ORM tool and have already made a couple of posts(queries) on this forum. So please bear with another one that I am going to put in.
I shall be building an application which shall expose a set of web services(Tech: VS 2005, SQL Server 2005). So its obvious that I shall be using the adapter pattern.
I have been through the documentation of LLBLGen and various postings on this site.
Inspite of that, I have the following(preliminary) queries about the adapter architecture rendered by LLBLGen:
1) Is it possible to add our own(raw) SQL statements in the generated DAL and execute them?
Yes, though it's not recommended, but you can do this. You've to follow the same code as what's generated into the DataAccessAdapter for calling stored procs.
2) Does LLBLGen support optimistic concurrency model with TimeStamping updates?
Please consult the section about Concurrency control: using the generated code - adapter - using the entity classes - concurrency control
3) Can I change my CRUD methods to use Stored Procs instead of the parameterized queries?
No, unless you want to call the procs manually using ActionProcedures.ProcName... . LLBLGen Pro doesn't support that procs are called for saving entities instead of a dyn. query. For fetching data, you can use projections, as you might have read in the manual.
4) Do LLBLGen generated entities support partial loading of an object? e.g Say I want to load a set of properties(data) of the entity at one instance of time and another set at another instance of time. Is it possible?
Not yet, this is planned in v2.1, the next upgrade
5) Is it possible to join to tables that are not mapped to business entities in queries used by the DAL? This may be required for instance when I dont want to map some Master tables to business entities.
Yes, you can create EntityRelation instances in your code manually.
In addition to the above, I am looking forward to a few things that are coming up (e.g: Dotnet 3.0). They are as follows:
6) How well shall the business entities generated by LLBLGen gel with WCF's Data Contract?
WCF's designers find that webservices are about messages, so you should define the messages, not send entities back and forth. I haven't looked into WCF's specific features yet, though llblgen pro entities support remoting and webservices out of the box. However as said, for webservices look into messages, don't send large piles of entities back and forth, if you do that you're using webservices too low in your application stack.
7) How well is LLBLGen's upgrade path with respect to LinQ and vNext?
LLBLGen Pro has already more features than ADO.NET vNext will have and we'll add a Linq compatible layer when Linq is more mature (As it is changing a lot at the moment), so expect it somewhere H1 of 2007.