|
List Info
Thread: Re: Fields as data. Also Linq.
|
|
| Re: Fields as data. Also Linq. |
|
2008-02-23 09:59:26 |
On Sat, Feb 23, 2008 at 2:23 PM, Andrew Badera
<andrew badera.us> wrote:
> Not sure I'm understanding. Account, Order and Address
should all be classes
> (possibly entities), and either encapsulate, or have a
factory or manager
> type object that encapsulates; their construction
logic, including DAL
> stuff. It seems like you're thinking about this from a
data perspective, not
> an OO perspective?
Yes, that's exactly what I'm doing, and I'm claiming it's
the better
perspective, because it's both simpler and more flexible.
The
per-table OO machinery can be eliminated completely in favor
of just
dealing with everything as tables. Most of the business
logic isn't
local to a table anyway, so the OO idea of encapsulating
complexity
within a class definition doesn't apply.
> Why would you join orders to accounts? Assuming 1
account
> to n orders, each order is going to have an account ID
of some sort, right?
> So Account maybe has a member _address and a method
GetOrders() which
> populates List<Order>.
Or you can just perform a join, which eliminates the need
for all that
stuff, and gets you a view of orders with addresses,
completely
transparent - the business logic doesn't even need to know
the
addresses weren't originally stored with the orders.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "DotNetDevelopment, VB.NET, C# .NET,
ADO.NET, ASP.NET, XML, XML Web Services,.NET Remoting"
group.
To post to this group, send email to DotNetDevelopmentgooglegroups.com
To unsubscribe from this group, send email to
DotNetDevelopment-unsubscribegooglegroups.com
For more options, visit this group at
http:
//cm.megasolutions.net/forums/default.aspx
-~----------~----~----~----~------~----~------~--~---
|
|
| Re: Fields as data. Also Linq. |
|
2008-02-24 07:23:26 |
|
I came from a DB perspective myself, but I have seen the light. Well, actually, I started off as a kid in procedural and structural stuff, then moved into DB-driven ASP apps, then moved into Java then C# OO, and nowadays, SOA ... so I'd like to think I've seen the spectrum, though I lack a lot of heavy concurrency experience, and have almost no purely functional experience.
Here's the biggest kicker: databases are expensive to scale -- at least until you get over that first hump, into the clustered/federated world. Even then, it's cheaper to scale your services tier than database. For example, for under 2 grand I can throw a new remoting blade into the rack. How much does a SQL Server box, with licensing, cost? For enterprise-grade stuff, you're talking twice that, AT LEAST, plus the administration overhead.
It's an easy trap to fall into -- letting the RDBMS do your "OO" work for you. But there are a million reasons that OO is sex, and DB as middle tier is pain. It's a lot easier to maintain and enhance your business logic if it's sitting in your middle tier, than it is sitting in your database. It's a lot easier to test, it's a lot easier to communicate, a lot easier to port, etc. etc. And I don't care if you're using "only" stored procedures, and not functions, not all the CLR stuff 2005 introduces, business logic doesn't belong in the database.
SQL Server 2005 of course introduces that CLR capability to the data layer, muddying the waters further -- but these exact same arguments still apply. Database is expensive to scale, and business logic gets murky and entangled. We've had numerous discussions on using this stuff at my day job, and we have yet to come up with a valid argument, in our minds. And I say this, being on the side of "toys! sex! let's use the CLR in the DB!!"
As far as "you can always perform a join" I'd have to ask if you've considered the performance implications. Joining to produce higher-level relationships abuses the crap out of the DB. If all you ever have is small line of business apps, maybe stuff serving 3-4 people, and you never need nor want higher efficiency or better performance, then please, by all means, abuse the crap out of your database -- if I'm not sharing the box with you, I don't care. But it's just not the engineering-minded thing to be doing.
On 2/23/08, Russell Wallace < russell.wallacegmail.com">russell.wallacegmail.com> wrote:
On Sat, Feb 23, 2008 at 2:23 PM, Andrew Badera < andrewbadera.us">andrewbadera.us> wrote:
> Not sure I'm understanding. Account, Order and Address should all be classes
> (possibly entities), and either encapsulate, or have a factory or manager
> type object that encapsulates; their construction logic, including DAL
> stuff. It seems like you're thinking about this from a data perspective, not
> an OO perspective?
Yes, that's exactly what I'm doing, and I'm claiming it's the better
perspective, because it's both simpler and more flexible. The
per-table OO machinery can be eliminated completely in favor of just
dealing with everything as tables. Most of the business logic isn't
local to a table anyway, so the OO idea of encapsulating complexity
within a class definition doesn't apply.
> Why would you join orders to accounts? Assuming 1 account
> to n orders, each order is going to have an account ID of some sort, right?
> So Account maybe has a member _address and a method GetOrders() which
> populates List<Order>.
Or you can just perform a join, which eliminates the need for all that
stuff, and gets you a view of orders with addresses, completely
transparent - the business logic doesn't even need to know the
addresses weren't originally stored with the orders.
--
--Andy Badera
http://andrew.badera.us/
andrewbadera.us">andrewbadera.us
(518) 641-1280
Google me: http://www.google.com/search?q=andrew+badera
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "DotNetDevelopment, VB.NET, C# .NET, ADO.NET, ASP.NET, XML, XML Web Services,.NET Remoting" group.
To post to this group, send email to DotNetDevelopmentgooglegroups.com
To unsubscribe from this group, send email to DotNetDevelopment-unsubscribegooglegroups.com
For more options, visit this group at
http://cm.megasolutions.net/forums/default.aspx
-~----------~----~----~----~------~----~------~--~---
|
[1-2]
|
|