Microsoft tries to helping object developers to close the gap between the relational world and the object world.And they call this "object modelling approach" Dlinq.
Using "custom business entities" in enterprise programming with Dlinq might seem the best thing after "sliced bread" but it isn't.
For my part I have written my Mappers and used commercial OR/M tools.
They mostly provide the same thing.
__Read the table from the database.
___Put that into a some HELPER thing.(DAO,DAL,ORM)
____Put that into your custom business object
_____Read from your business object.(if u can :) )
I see NO REASON for this "Unnecessary Pull and Push".
Can anybody explain me why we shouldn't use a typed dataset and go to OR/M
I hear people saying Typed dataset is really concrete and not flexible to requirement changes.
U even might lose staff when u have to regenerate it.It is far away from perfect.But with typed dataset...
1.U can easily see design time errors + intellisense
2.They also provide rich data for paging,sorting and all kinds of UI staff.
3.For requirement changes,for performance and also for JOINS u should use VIEW's in database modelling.U can also use VIEW's with typed datasets in ADO.net 2.0.really nice graphical component.
On the other hand "object modelling approach" makes NO sense.As to access a group of data,u have to create a custom collection where it is the WORST thing u can do in the business software development in terms of performance.(Arrays are evil).Such as 12 million ORDERS,can have 55 million ORDER_DETAILS and 5 million CUSTOMERS and no LAZYLOADING can help u.Object models use RAM and CPU resources which are really important in terms of performance.if u have more complicated object graph it will be slower.Some might say lets take the performance parameter out and think without it,those people see a "butterfly effect" on their project when they realize that they got to rewrite the application all over again.
So I am really hard on OO but I must admit that Object oriented modelling is a nice theory.(...an idealism that does not work in practice).
if u really go into object domain modelling.U will end up with all these things which are really not neccessary...
U have to deal with
A.identity Maps(read objects only once)
B.UnitOfWork(Transaction mechanism for your objects)
C.Topological Sort(To have right insert ,update orders)
D.Mappers(OR/M buy or build it...MS did not do objectspaces which was a cool decision)
E.Repositories(common place to retreive your collections,if u can...)
F.Specification patterns / Query objects(filtering mechanism in objects,functors anonymous methods,POEAA)
G.Metadata Techniques.(some cool SQL reuse that makes the system slow,through code generation or reflection)
H.Design Patterns like FACADE to put everything under the rug...
Do u think is it worth it
Also at the end of the day,u will face the fact that u need performance.(as the users say so it is Google time!,they just don't wanna wait,time is more valuable than money...)
Carefully looking at your UI code behind,u can easily find out that every user interface in your application has different aspects of data.And there is no ONE most important aspect.(Like u can't love your mum more than your dad...)
Object Models are not build to have many aspects of data as when designing them OO people don't think in a tabular way,they do think in a object way which is slow as their logic is eating RAM and CPU resources which are expensive.They are trying to reinvent the RDBMS idea at runtime.So every VIEW must be differently aligned for your business application user interfaces for performance.
Yes typed dataset approach is not the BEST, but people should also know what they are getting into OR/M world.
The Failure of OO developers is that they are tend to be see OO as a GOLDEN HAMMER.But the business software development has many aspects that,it is not wise to build an "OO Domain Model" where the world is consisted of objects.if u think about it tables are also everywhere in business enviroment.Table is an abstact logic to organize big amounts of business data.Like the simpliest example is;when u go to a train station , u never see OO chart of trains,the thing u see is a table with coloumns and rows telling u where to go and when to go.
I don't mean do not use OO, we should all use OO for some UI staff, but it is just no GOLDEN HAMMER that can solve every problem.LinQ on the other hand is nothing more than an OR/M tool replacing the old idea of objectspaces.(where is it again ...)
So why do I write all these staff , to discourge c# 3.0 team
OfCourse not!it is a really nice attempt to try to close the gap between the RDBMS and objects.But the practice and the theory doesn't have to match in daily life of a programmer.
Microsoft should invest time and money in typed datasets, not in OR/M idealism where there is no logical end.
PS: Myth: OR/M vendors might claim if u don't do OO , u will end up with a non adaptable code,spagetti code.
:=) Adaptability is in your head,not in your code...
Why will LINQ fail ?
Filipe Janela
Jun Fang
I agree here. LINQ just by itself will be a valuable addition for anyone who works with arrays and/or collections. Remember that not every application is an enterprise application with SQL Server farms etc. Applications that work on local files will benefit greatly from these enhancements to C#.
Ali883945
http://blogs.msdn.com/aconrad/archive/2006/03/14/551685.aspx
Fnord
Urip
I agree with you here. LINQ's most value comes when I use it along with Workflow's activities by querying objects, graphs, arrays or collections at runtime dynamically or some other equivalent things. The data source of this could not necessarily be a strongly typed dataset, xml document, rdbms etc. It could be anything like collection of service objects, data returned from remote objects etc. I see a huge benefit.
Just my 2 cents.
Seclymer
Next Linq Tech Preview Teaser
DataSet... Linq... hmmmmmmmm.
__________________________________________________________________________
Dlinq will be ready at 2010
Lisa Morgan
Just a clarification: where you say Linq, you mean DLinq. The two follow the same pattern, and most people are very focussed on the DLinq implementation of Linq (to the exclusion of any other *possible* implementation), but the two have very different scope: RDBMS vs in-memory enumerations.
Linq, in fact, knows nothing about SQL or OR mapping.
clark k
Augie
You obviously have had a bad experience with an OR mapping based project. OR projects are not all the same.
1) Yes, if you want a good design you need to keep in mind that your design must map well to a relational database. Anyone that things they can take an arbritrary object hierarchy and persist it to a relational database is misguided.
2) The value of LINQ is not so much in the OR mapping, as that is more or less mature, but in the fact that the queries themselves are being checked by the compiler.
3) The fact that the current LINQ prototype fetches the complete result set rather than using cursors (if it in fact does that) would be a real concern. But, since it is only a prototype and not yet production code, we can hope that they will understand this and fix it before release. It may use cursors under the covers and appear to be a collection, or intend to be that way for release.
I think your comments raise valid concerns, but make a lot of assumptions about LINQ that I am not sure are valid. Thanks for the cautionary warnings.
Brian Leach
DLinq is part of Orcas.
Orcas delivers the programming tools for Vista.
Vista is coming out real-soon-now. (According to some bloggers and journalists, November.)
To be useful for Vista, Orcas must go RTM in a timely fashion.
2010 is not timely.
BW88159
I just wanna add that being an ado.net fan from the beta 1 of .net 1 I am a bit tired of it and see ORM as a better approach when dealing with databases - at least for 90% of operations. If you use a good ORM wisely and carefully you might gain huge in productivity and maintenability while the performance hit is minimal. That said, Linq only adds to the gain end ease of use.
And DLinq is/will be a good ORM that consumes Linq features. But nothing prevents you to use Linq in combination with other ORMs (once they support it - believe me, they will) or even for doing selects into a dataset (or anything else you deem useful).
Scale_Oven_Stove
And Whidbey released in 2005, anyway. If you want to apply constant-time-per-release, that would put Orcas at 2008.
If Orcas is released in 2010, I'll drink a 6-pack of the beer of your choice.
(For the unaware, I don't like beer at all...)
ABT-BSM
So who is this "U" person, anyway
Seriously, I'm not sure I have the slightest idea what you're talking about. Could you perhaps restate your point, with a bit less bombast and a bit more grammar
Linq isn't stricly about relational data access (although DLinq is, certainly). Linq, as far as I can tell, doesn't abstract the relational algebra sufficiently, so it's not really "working in that space" as they say. From what I can see, Linq is primarily about sequence comprehensions (related to list comprehensions, extended over infinite lists).
Now, what DLinq has done to map Linq onto relational access is truly amazing, to be sure. And it's had the side effect of developing some interest in expressions-as-concrete-entities, which I think is a Very Good Thing for C#. That said, DLinq has some rough edges that I think will need to be worked out.
The one bit in your post I think I understood was your question about strongly typed datasets. DLinq works in conjunction with SQLMetal, which essentially generates strongly typed classes for SQL Server tables (in much the same way XSD.EXE generates typed datasets from schemata, or VS2K5 generates typed datasets through a database connection). Although they're not identical to System.Data.DataSets, they function in a similar capacity for DLinq queries.
truetype
Lets look at reality.(not OO idealism)
release dates.
.net 1.0 > 2002
.net 2.0 > 2006
orcas > the best 2010.
TheBadmojo
That doesn't jive with any of the above, *or* the internal development schedules.
It's not idealism, it's realism -- Orcas isn't meant to be the big churn that Whidbey was. No big changes to the type system, etc. And there's always Vista that needs dev tools, and that's not going to wait 4 years.