LINQ to SQL and 3-layered-structure

[Peter]

Hi

we have traditionally developed applications with a 3-layer
architecture:

(1) a presentation layer (including ascx and code-behind);

(2) a service layer (providing an "api" for use by the presentation
layer to obtain the data it requires);

(3) a data-access-layer (providing for interaction with a data store,
mostly a database);

In addition to these "layers", we usually make component interface
assemblies which contain relevant interfaces for each component (for
example an IUserService or ICustomerDal); and a data assembly
containing concrete data classes used in a component for transporting
data between the layers (here for example a User class or a Customer
class).

Can this layered structure be maintained if LINQ to SQL or LINQ to
Entities is used for data access? Can LINQ to SQL conform to a
"data-access-interface" for example, so we can "swap out" the generated
data-access-layer with another dal via configuration?


Thanks,
Peter

 

[andy.johnstone]

Yes, you can continue to do this. I found the best solution is to
build a Business layer using the csla.net framework.

 

[andy.johnstone]

I use concepts of CSLA and roll my own, because I have used CSLA in the
past. The Business objects are the smart business objects that know how to
persist themselves to the model.

If you're doing something similar to Csla.Net, you should be ok. I
use it, and have been using L2S successfully in my DataPortal_XYZ
methods or encapsulating some L2S statements in CommandBase object.

HTH

 

[Mr. Arnold]

I use concepts of CSLA and roll my own, because I have used CSLA in the
past. The Business objects are the smart business objects that know how to
persist themselves to the model.

If you're doing something similar to Csla.Net, you should be ok. I
use it, and have been using L2S successfully in my DataPortal_XYZ
methods or encapsulating some L2S statements in CommandBase object.

I have been using CSLA when Rocky was doing a VB6 version of it. I got my
first .NET MCP back in 2004 because of my first implementation of a CSLA
C#.NET solution, which was Windows desktop base that used a Web server. Then
by contracting in various shops, I still used the CSLA concepts that I have
learned when I can use them. Really, all you need to know is how to
use/implement a form of that CSLA Base.Business object, which is the heart
of all of it. You can then do pretty much what you want to build n-tier
business solutions.

 

[Paul]

You can do Entities - Linq - SQL.

I looked at the fundamentals of doing this some time ago but the development
time decrease that is stated by many is flawed. Once you have a good
framework in place for your apps I think this approach takes longer and
suffers in performance, and hardcoding all those sqlesque statements. Hmmmmm
frightening.

OK

Putting the WSDL interface at the BLL Level allows you to call the same
business logic from anywhere. The UI uses the WSDL as its model. This is
where I have problems with CSLA, really good as it is it has a flaw in it
cannot utilise Web Services correctly. Properties which track changes to
themselves cannot track changes to themselves over SOAP, I have not tried
this with WCF so am unsure if this limitation remains although I think it
must. There is a simple way to track changes over SOAP add a property
underlying values which is a type of the parent Type. Populate this getting
from the database.

Call a save method and pass the object back over soap. Changes can be seen
by matching the properties with the properties in underlying values. Very
simple old fashioned but works. New records are identified by a null
underlying value or an id of 0.

The addition of a isarchived flag in a model base allow you to deal with
deletions/archives.

All these popultaeunderlyingvalues/isnew,haschanged can be done with
4-5lines of refection code in a modelbase.

anyway this is the structure I would aim for.

U |
I | Windows Services or Web Site or Forms app
_______________________________________________________________
| BUSINESS LOGIC FACADE (WS/WCF)
|
|
|
| DATA HANDLER | BLL
HANDLER |
B | ____________________________________________________________|
L |
|
L | Distinct Business Logic entities
|
|
|
_______________________________________________________________|
| Converts SQL DataReaders to Model objects similar to Linq but you have
more control of the DB Access|
D |
|
A | Only use the Data interfaces in this level then you can always
L | switch to any db at a future time.
|
|
______________________________________________________________

DATA Provider FACADE/FACTORY
_______________________________________________________________

ORACLE DATA PROVIDER SQL DATA PROVIDER MY SQL DATAPROVIDER
_______________________________________________________________