Just today I decided to download LLBLGen to see exactly what it can do. Pretty awesome software, and generates clean code IMO. However, all this time I've been using MS DAAB, and I'm not sure if i should make a switch, not use it, or use it in conjunction with
the rest of my DAL. Here are my questions: 1. LLBLGen Seems to generate all the basic CRUD classes and sp's, and this is very helpful. However, I still have much more complex queries, so do i continue to use DAAB for these, or should I try and extend the generated
LLBLGen? 2. I currently use (and love) the feature of passing in ordered values into SqlHelper without haveing to build the SqlParameters. However, in order for this to be possible, the DAAB has to first query the metadata for the stored procedure before actually
executing the query. Is this double hit on the database expensive? 3. How easy (or tough) is it to manage a changing database schema after using and customizing code generated with LLBLGen? 4. What is the best way for my Business objects to interact with the
DAL created by LLBLGen? An example would be great. A couple more questions slightly related: 5. When a page with multiple controls, each with their own data needs, request to query the database, is it better to bundle all the queries into one request, query
the database with a stored procedure that executes several other stored procedures, returns a dataset with multiple datatables, and each control grabs it's requested data? I don't even know if this is feasible, considering i've got several controls each doing
their own thing on any given page, requesting data independantly of every other control. 6. If anyone has seen some of my posted code, you can see that my business tier is all screwed up. I need to know best practice of how my presentation layer should talk
to my business layer, what exactly should make up my business layer, and how my business layer should talk to the data layer. An example that I'm just dying to see is something where a Product is created, filled, inserted, and the result is returned all the
way back to the presentation layer so that a Confirmation message can be displayed. My app does this already, and im sure most anyone can do this.... but to have each tier only talking to the tier next to it, and to have each tier only performing functions
it is supposed to....that is the challenge for me. Whew! Now if even half of these questions can be answered, i'll be a happy guy.
Hello. I currently make use of a heavily modified version of the microsoft DAAB to handle my data access and are very very pleased with both performance and ease of use. So lets see... Question 2. Yes. By simply passing the values to the DAAB and leaving the
work of deriving the parameters to the DAAB does double the calls needed to perform one query. It does however cache the parameters for future use based on the connection string and the stored procedure name. So if you do use runtime parameter discovery make
sure your connection string is the same for each call to speed up subsequent calls to the same SP. Call me crazy, but i actually do write the parameters then pass the parameter array into the DAAB. I make use of dynamic parameters for initial testing and fiddling
around before i call it good and move on. Since i know everything that is going down in the SPs i can rest at night knowing that i gained performance by seeing the simple job of typing out the parameters through. As for the business layer... (question 6 and
mabye parts of 5) The general structure of my business objects are as follows: Each object represents a piece of functionality as a whole. So i have a class Products, a class Accounts, a class ShoppingCart, etc... Each class (that writes new data to the database)
has a list of properties and methods to manipulate data within the properties and database. So i have a method save that checks to see if the field product is is there. If so call the private update function, if not call the private insert function. So to
insert data or update data, i create an instance of the class, call the getData function (if necessary) which fills the properties in the class. Once complete i call the save function and bam, it is done. Most classes also have a list of shared functions that
are used to manipulate data when an instance of the class is not needed. Like deleting a field. I do not need an instance taking up memory to simply pass in the id of the item being deleted. I also use shared functions that return a dataset or datareader when
passed an id. My presentation layer and web services just create an instance or call shared methods of the class they need data from. I try to encapsulate as much of the needed data as possible in each class. However, as you mentioned, i also have a bunch
of random data happening around the page, so typically, the main data needed for a page is taken care of in one sweep while, say, banner ads and such make calls individually. To aid this, I am investigating in having the main data be filled, then opening a
connection and passing it to each additional object that needs data. So if a page has a datalist and 4 ad banners, i can get the datalist filled, open a connection, fill the 4 banners, then close the connection... Perhaps this may shave some time off by not
having to open a connection with each object. More on that later... Anyway, hope my scatterd examples help.
My business objects are created, used, then discarded with each page request where they are needed. This usually tends to be in the page load event or in the method that handles a particular action such as a button click.
Great stuff mike, very helpful. Can someone explain to me the idea of persistance? Since we are dealing with web applications, and therefore stateless applications, I dont know of ways to create persistance besides viewstate, sessions, etc. I might be totally
off on this...
Wel, the idea is - nonexistent. Especialy with ciewstate and users sometimes taking half an hour to fill out a form. Just dump the objects, and refetch them on the next round trip to the server - keeping persistent objects outside of the viewstate (which is
great for storing object primary key values) makes little sense.
>>Just dump the objects, and refetch them on the next round trip to the server - keeping >>persistent objects outside of the viewstate (which is great for storing object primary key >>values) makes little sense. Why? We could use Cache and fetch them when needed.
ViewState is bad, Session not always but Cache is recomendable...
::Why? We could use Cache and fetch them when needed. Possibly, but this is WAY more complicated than you think. * The postback could come 10 minutes later. What do you do if the object has changed? Ignore this? One minute later the ojbject could be valid in
cache, but changed in the database. Most of the time the simplest solution is better :-) Not said that we dont work on a caching system for our own systems, but this has to be pretty elaborate.
Late to the thread, I'll just toss in a couple of thoughts triggered by other posts: ** What do do about DAAB and parameters? And what about LLBLGen? I like that LLBLGen generates the parameters and SPs for you in one pass. And can be aimed at a new table,
or such. But I'm not real kean on passing it's style of object up through layers. Otoh, I really like the DAAB, except for the extra hit on the parms. SO, I've tried generating LLBLGen code to get the sprocs and parameter creation lists, then I write my own
DAB using DAAB. It's faster than writing the DAB with DAAB alone, because you're copying the parameter lists for the insert/update/delete stuff, and it saves writing the sprocs yourself. AND!!! Since LLBLgen comes with source code, I've tweaked it to write
the sprocs a bit different to fit my style, and I'm gradually working my way through a making a version that just generates the DAB for using the DAAB the way I like to use it ALONG WITH nUnit test classes for the whole shebang. ** About how to organize business
objects. I struggled with this a number of years ago until I had a BFO on the matter that was triggered by working through a design using Use Cases. Create a business object for each main Use Case. For example, one use case is "Prepare Order", so you have
a business object that supports all that is needed for that. It knows which DAL elements to call to get the data, how to update the data, extra steps in the update that the UI doesn't need to know (like "send approved order to warehouse for shipping"). Often
business objects call each other as well. Just some thoughts on one way to approach it.
::About how to organize business objects. I struggled with this a number of years ago until I ::had a BFO on the matter that was triggered by working through a design using Use Cases. I dont want to be to negative, but if you would present this in any roject
of mine as an OO model, I would send you into an introductory course for OOAD, and definitly remove you from responsibility of the design until you have another BFO. Having a business object called "PrepareOrder" that only knows how to prepare an order and
to talk to the DAL about preparing an order is a lot of good things, but it is NOT an object oriented system. It is the kind of twisted insane OO that MS has been pushing around for a long time. Have you ever had a look on working with business objects? The
type where you have Order and OrderItem classes that you create and attach, and then just commit on the business layer which takes over all responsibility? Besides that non eof the classes should know how to talk to the DAL - it is not the business of a business
object to talk to the DAL.
sjmueller
Member
359 Points
73 Posts
LLBLGen vs. Microsoft DAAB... Plus More
Aug 16, 2003 01:23 AM|LINK
mdwan
Member
75 Points
15 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 19, 2003 04:24 PM|LINK
netLearner
Participant
930 Points
187 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 19, 2003 04:53 PM|LINK
mdwan
Member
75 Points
15 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 19, 2003 11:10 PM|LINK
sjmueller
Member
359 Points
73 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 22, 2003 03:58 AM|LINK
thona
Member
20 Points
2923 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 22, 2003 07:08 AM|LINK
netLearner
Participant
930 Points
187 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 22, 2003 03:15 PM|LINK
thona
Member
20 Points
2923 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 22, 2003 04:02 PM|LINK
JimRoss [MVP...
Star
10080 Points
2008 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 22, 2003 10:34 PM|LINK
MS MVP ASP.NET [VC++/MFC emeritus]
Old Dog Learns New Tricks
Preferred programming language: cuneiform on clay tablets
thona
Member
20 Points
2923 Posts
Re: LLBLGen vs. Microsoft DAAB... Plus More
Aug 23, 2003 03:46 AM|LINK