Another entity class question
For any of the Fog Creek folks (or anyone, for speculation):
I enjoyed reading about the entity classes; I did something similar on a recent project. I was wondering about a couple of details.
1) The description hints that an entity class may hold the results of a more complex query, not just all fields from one table; it also says that the field values can be updated. What if the query includes aggregate functions? Is there a restriction to prevent this?
2) The entity classes seem to hide the details of recordset interaction; what (if anything) hides the SQL used to get the specific set of records you want? In other words, how is the query set up to begin with?
Thursday, January 16, 2003
I'll respond to your second question as to how we go about doing it:
We almost always use stored procedures to encapsulate the SQL. Our "entity" (data access) layer classes usually just calls upon the stored procs.
The code is cleaner and free of SQL statements littered everywhere. And the SQL is localized in the stored procs. If we change the tables, etc. then we only need to look at the stored procs. This is extremely useful when we have several apps that access the db and use the stored procs. If you just have one app then this doesn't give you much since you can also just as easily do a search in your entity classes.
Another benefit of putting the SQL in stored procs is that the queries run faster since the db server doesn't have to parse and build a query tree every single time. However, this speed boost will only be noticeable in systems with many users and several simulateanous queries. (Think eBay, Amazon, PayPal, online banks, or most of the eccomerce sites out there).
Just wondering .... is anyone working with COM+ (not just regular COM/DCOM) and/or doing DTC stuff for anything out there?
Friday, January 17, 2003
Thanks for the information!
Monday, January 20, 2003
HeyMacarana, We're using COM+ (EnterpriseServices) in .NET. Works fine, was easy to implement, but if you are doing any intensive database work (i.e. transferring tons of data in bulk) expect a 10% hit in performance time.
And yes, we are using stored procedures for our data access. The only drawback with stored procedures is that it is easier to create dynamic queries if the SQL is in the code (i.e. adjusting the where clauses, sorts, etc.)
Thursday, January 23, 2003
Fog Creek Home