My company has implemented a number of successful solutions using CSLA 2.x as the basis of the business layer, linking through to SQL Server databases by calling sprocs via ADO.NET in the DataPortal_X methods. Now a colleague is telling me that when we implement new applications, we can give up on both CSLA and sprocs, because instead we can use LINQ To SQL. It will generate a load of classes that we can use as the basis of our business layer, and any custom business logic can be added to those classes via the partial class mechanism.
I know a bit about LINQ, but I haven't had time to properly evaluate the features of LINQ to SQL or the code-generated classes that it creates. My instinct is that abandoning CSLA for L2S is a bad idea, and my research on the subject seems to confirm this - elsewhere Rocky says that this will be "very painful for anything but the most trivial of applications".
My question is, has anyone tried this method of using L2S, can anyone comment on the practicalities of this approach versus using CSLA? What are the features of the L2S code-generated classes that cause them to not make "embedded business logic maintainable or easily reusable"?
Thanks in advance,
Richard
Linq to SQL is a Microsoft version 1 technology. (And we all know that we have to wait for version 3, right?)
Whereas CSLA has been in use for 4+ years and is extremely solid.
I would never consider abandoning CSLA for an unproven technology.
See Rick Strahl's blog for some in depth discussion of the pain points around Linq to SQL. Focus especially on the loss of the DataContext when you try to use L2S across tiers.
Joe
Linq does not provide all of the functionality you get when using CSLA. Linq is only supported by Sql Server currently (possibly Access).
Linq and Linq to Sql can be used hand in hand with CSLA. Rocky has some good examples of using Linq in CSLA in the Project Tracker on CSLA 3.5 beta 2.
Linq to Sql can also access stored procs, so no reason for those to go away either.
> Linq to Sql can also access stored procs, so no reason for those to go away either.
So then the only thing that would be changing is that inside the DataPortal methods, instead of doing ADO.NET Connections, Commands and so on, we'd be using L2S instead. Would there be any benefits to making that switch at all?
Richard
There are a couple reasons that I prefer Linq in the DataPortal methods. The first is that calling a stored procedure with linq isn't more complicated then calling a method to an object. You just need to instansiate a context, then call the method. Another reason is that it provides Compiler time checking and data type checking. You don't have to worry if you've misspelled a proc, parameter, or table name. It also simplifies dealing with connection management.
You can also use regular Linq on your csla collections for filtering/sorting/grouping etc.
Since I've been moving to Linq where I can (I still have to hit Oracle databases on most projects ![Sad [:(]](/emoticons/emotion-6.gif)
), I've been impressed and like it quite a bit.
rjn123:
> Linq to Sql can also access stored procs, so no reason for those to go away either.
So then the only thing that would be changing is that inside the DataPortal methods, instead of doing ADO.NET Connections, Commands and so on, we'd be using L2S instead. Would there be any benefits to making that switch at all?
I think it depends on what you are comparing it to.
Compared to raw ADO.NET L2S is slower, but much more readable and it requires less manual coding. So in the new ProjectTracker code I switched from raw ADO.NET to L2S and I'm very happy.
And since I'm using stored procedures via L2S the performance is no different for insert/update/delete operations - there's just a small perf hit on data retrieval. For me this seems like a great compromise! I'm very much enjoying using L2S.
But if you are already using an ORM tool (one of the many out there) then I'm guessing you'll find little or no value. As some people have pointed out, L2S is a v1 technology, while many of the other ORMs out there have been around for years and provide some very nice features.
Also you must consider that the ADO.NET Entity Framework is coming later this year. It is not unlike L2S, but is a broader, more powerful technology. It also fits the same niche within the CSLA world - as a replacement data access technology within the DataPortal_XYZ methods - but it provides support for more types of database and more complex mapping schemes than L2S.
So for smaller, simpler SQL Server scenarios I think L2S is awesome. Really wonderful and fun!
But more non-SQL Server scenarios you'll need something else. And for more complex mapping scenarios you'll need something else. ADO.NET EF is a candidate, as are various other tools out there.
This whole discussion highlights exactly why I've refused, time and time again, to tightly couple CSLA to any one data access technology. If I'd have gone for ADO.NET, or the DataSet then CSLA would be in trouble right now. If I go for L2S over EF (or visa versa) I am gambling on which (if either) will win.
And history has shown that no Microsoft data access technology lasts longer than 5 years. Ever. And the average time one lasts is just 2.6 years. Seriously. Personally I want CSLA to remain relevant longer than 2.6 years, so I've very cautious when it comes to coupling tightly to any of these data access larks Microsoft embarks on every couple years...
...
This whole discussion highlights exactly why I've refused, time and time again, to tightly couple CSLA to any one data access technology. If I'd have gone for ADO.NET, or the DataSet then CSLA would be in trouble right now. If I go for L2S over EF (or visa versa) I am gambling on which (if either) will win.
And history has shown that no Microsoft data access technology lasts longer than 5 years. Ever. And the average time one lasts is just 2.6 years. Seriously. Personally I want CSLA to remain relevant longer than 2.6 years, so I've very cautious when it comes to coupling tightly to any of these data access larks Microsoft embarks on every couple years...
This was a significant factor in our choosing CSLA -- that it wasn't in any way dependent on the underlying database access technology.
We had a prototype running under an ORM, and I converted it to run using CLSA in just a couple of days, and it still uses the same ORM. I could swap the ORM with another data access layer and the business logic of our application wouldn't be affected.
CSLA provides other added value over whatever data access method is used -- multi-level undo, validation rules, and role-based authorization rules, and flexible tier configuration (2-tier, 3-tier, etc.).
Thanks for your reply, Rocky.
> But if you are already using an ORM tool (one of the many out there) then I'm guessing you'll find little or no value. As some people have pointed out, L2S is a v1 technology, while many of the other ORMs out there have been around for years and provide some very nice features.
My company is not already using an ORM tool. And historically it has proved much easier to get my colleagues to use a new MS technology than it is to get them to use a third party or open source tool. (CSLA is the exception - after much pushing from me and a few of the other staff). So L2S may be a good way to introduce my colleagues to ORM. And maybe the benefits of code-gen too (something else I am trying to push).
The applications we write are typically small, almost always web apps, almost always SQL Server, and almost always a new db with the structure under our control.
The comments I've had on this thread so far have all reinforced the ideas I have been formulating... so thank you all.
Serializing objects and data is just a small part of CSLA.net. I can't image the Entity Framework or Linq replacing the validation, authorization, n-level undo, and multi-tier design issues that CSLA solves.
Serializing objects and data is just a small part of CSLA.net. I can't image the Entity Framework or Linq replacing the validation, authorization, n-level undo, and multi-tier design issues that CSLA solves.
You know, this opens a question that, at least to me, might be worth it's own thread...
Not because I think it would involve a ton of debate (though it could.) But mostly because the question has little to do with the topic of this thread. And because it's mostly a question for Rocky. So...
Rocky: what would you do if one of MS's larks was to "buy" CSLA off of you and turn it into one of their technologies? There are certainly a lot of hurdles in that kind of situation, and I'm not in any way suggesting it as a good idea. But considering what CSLA does, and considering where MS seems to be going with some of their stuff, turning CSLA into an "official" MS product - either through licensing, outright purchase, or some other form of appropriation - does not seem entirely out of the question. After all, MS has bought their way out of certain problems before...
On the other hand, I think it might be a difficult sell for them to take something like this (i.e. something that directly produces revenue for you and Magenic) and "bring it in-house". Compensation for you is one thing, but considering (and potentially compensating for) the effects on Magenic might be a whole different ball of wax.
The big problem I see is that a lot of these types of things tend to get pushed by some folks in MS and then they die off from lack of support. And while it is starting to get better, MS doesn't have a huge track record of giving something back to the community to support.
Just curious...
- Scott
I'm not holding my breath on something like that ![Wink [;)]](/emoticons/emotion-5.gif)
Microsoft typically acquires these sorts of things to get the employees - the IP in their heads - more than anything else. And while I've been courted to work there a few times, I really have no desire to move to Redmond (and more importantly nor does my wife).
I really have no desire to move to Redmond.
Rocky,
They have this new fangled technology called "The Internet".
They also have some new business practices called "working from home" - I think it is called tele-commuting.
I have been doing it for a decade now.
Works OK for me and my family.
Joe
Yeah - but that makes Assimilation a whole lot harder. After all, you have to send the equipment to him, and then hope he hooks it to his brain so they can directly plug in via this new-fangled technology... ![Smile [:)]](/emoticons/emotion-1.gif)
Rocky - if that's the main intent, then it begins to make more sense why some of these projects die. It's unfortunate, though - some of them were actually pretty decent.
And as for moving to Redmond - I live in Iowa, and right about now, I might trade the Midwest winter for some rain...
- Scott
... L2S may replace things like NHibernate and other DTO frameworks, but Csla isn't a DTO framework, its a business object framework.
Until it supports more databases, I don't see L2S as providing any real advantage over a DTO framework . We're using CSLA with the Wilson ORMapper to provide a DAL, and it works great. Not only that, but I was able to plug in Oracle's ODP.NET data provider with an hour or so of work, so we now support 4 different providers and 3 databases (SQL, Oracle, and Access). When L2S can do that, then I'll look at it...
Copyright (c) Marimer LLC