LINQ dataContext methods - should you put business logic there?

[Andy B]

I was just wondering, when you create dataContext methods, should you put
business logic there to try and minimize pushing data through 2-3 layers of
code? or should the business logic still go in another class somewhere
making it access the dataContext methods?

[Dmitry Perets]

On 13 ÁÐÒ, 23:13, "Andy B" <a_bo...@sbcglo bal.netwrote:

I was just wondering, when you create dataContext methods, should you put
business logic there to try and minimize pushing data through 2-3 layers of
code? or should the business logic still go in another class somewhere
making it access the dataContext methods?

What do you mean by dataContext methods? If you mean the methods of
your DataContext class (or subclass actually), then I think that the
answer should be "no". The purpose of DataContext is to bring tables
from db and then persist your changes back to the db. And this is
exactly what the DataContext should do. Then your next tier can be
some kind of MyApplication.S ervices, and this is the place for your
business logic. There you'll have classes like LoginService,
CustomerService , OrderService etc., these classes will talk to
DataContext when they need. Note that these classes will be those
where you can put LINQ to SQL queries etc. I think this kind of design
is preferable, because you benefit a multi-tier architecture instead
of pushing all the stuff into one big class. And btw, in this case you
can use LINQ Designer to generate your DataContext class...

[Andy B]

So, the linq designer in a sense, is like the dataSet designer? And linq is
sort of like a different way of making a dataSet. They are both different
things, but from what I can see so far, they sort of work the same on the
outside edges?
"Dmitry Perets" <Dm***********@ gmail.comwrote in message
news:2f******** *************** ***********@m71 g2000hse.google groups.com...
On 13 ÁÐÒ, 23:13, "Andy B" <a_bo...@sbcglo bal.netwrote:

I was just wondering, when you create dataContext methods, should you put
business logic there to try and minimize pushing data through 2-3 layers
of
code? or should the business logic still go in another class somewhere
making it access the dataContext methods?

What do you mean by dataContext methods? If you mean the methods of
your DataContext class (or subclass actually), then I think that the
answer should be "no". The purpose of DataContext is to bring tables
from db and then persist your changes back to the db. And this is
exactly what the DataContext should do. Then your next tier can be
some kind of MyApplication.S ervices, and this is the place for your
business logic. There you'll have classes like LoginService,
CustomerService , OrderService etc., these classes will talk to
DataContext when they need. Note that these classes will be those
where you can put LINQ to SQL queries etc. I think this kind of design
is preferable, because you benefit a multi-tier architecture instead
of pushing all the stuff into one big class. And btw, in this case you
can use LINQ Designer to generate your DataContext class...

[Dmitry Perets]

Yes, almost. I would say, they both serve for the same purpose, but
LINQ to SQL provides more convinient and object-oriented approach. So
you don't work with DataRows and DataColumns (like you worked before),
you just work with objects. These objects can serve you in all your
tiers. And pay attention that LINQ Designer creates these objects for
you, which is not happenning with DataSets...

On Apr 14, 1:17*am, "Andy B" <a_bo...@sbcglo bal.netwrote:

So, the linq designer in a sense, is like the dataSet designer? And linq is
sort of like a different way of making a dataSet. They are both different
things, but from what I can see so far, they sort of work the same on the
outside edges?

"DmitryPere ts" <Dmitry.Per...@ gmail.comwrote in message

news:2f******** *************** ***********@m71 g2000hse.google groups.com...
On 13 ÁÐÒ, 23:13, "Andy B" <a_bo...@sbcglo bal.netwrote:

I was just wondering, when you create dataContext methods, should you put
business logic there to try and minimize pushing data through 2-3 layers
of
code? or should the business logic still go in another class somewhere
making it access the dataContext methods?

What do you mean by dataContext methods? If you mean the methods of
your DataContext class (or subclass actually), then I think that the
answer should be "no". The purpose of DataContext is to bring tables
from db and then persist your changes back to the db. And this is
exactly what the DataContext should do. Then your next tier can be
some kind of MyApplication.S ervices, and this is the place for your
business logic. There you'll have classes like LoginService,
CustomerService , OrderService etc., these classes will talk to
DataContext when they need. Note that these classes will be those
where you can put LINQ to SQL queries etc. I think this kind of design
is preferable, because you benefit a multi-tier architecture instead
of pushing all the stuff into one big class. And btw, in this case you
can use LINQ Designer to generate your DataContext class...

[Andy B]

How do you put business logic inside of dataContext methods? When I was
reading up on them, the only thing it looked likeyou could do was to create
methods that just called stored procs on the database. Am I wrong?
"Dmitry Perets" <Dm***********@ gmail.comwrote in message
news:a1******** *************** ***********@f63 g2000hsf.google groups.com...
Yes, almost. I would say, they both serve for the same purpose, but
LINQ to SQL provides more convinient and object-oriented approach. So
you don't work with DataRows and DataColumns (like you worked before),
you just work with objects. These objects can serve you in all your
tiers. And pay attention that LINQ Designer creates these objects for
you, which is not happenning with DataSets...

On Apr 14, 1:17 am, "Andy B" <a_bo...@sbcglo bal.netwrote:

So, the linq designer in a sense, is like the dataSet designer? And linq
is
sort of like a different way of making a dataSet. They are both different
things, but from what I can see so far, they sort of work the same on the
outside edges?

"DmitryPere ts" <Dmitry.Per...@ gmail.comwrote in message

news:2f******** *************** ***********@m71 g2000hse.google groups.com...
On 13 ÁÐÒ, 23:13, "Andy B" <a_bo...@sbcglo bal.netwrote:

I was just wondering, when you create dataContext methods, should you
put
business logic there to try and minimize pushing data through 2-3 layers
of
code? or should the business logic still go in another class somewhere
making it access the dataContext methods?

What do you mean by dataContext methods? If you mean the methods of
your DataContext class (or subclass actually), then I think that the
answer should be "no". The purpose of DataContext is to bring tables
from db and then persist your changes back to the db. And this is
exactly what the DataContext should do. Then your next tier can be
some kind of MyApplication.S ervices, and this is the place for your
business logic. There you'll have classes like LoginService,
CustomerService , OrderService etc., these classes will talk to
DataContext when they need. Note that these classes will be those
where you can put LINQ to SQL queries etc. I think this kind of design
is preferable, because you benefit a multi-tier architecture instead
of pushing all the stuff into one big class. And btw, in this case you
can use LINQ Designer to generate your DataContext class...

[Andy]

On Apr 15, 7:17 am, "Andy B" <a_bo...@sbcglo bal.netwrote:

How do you put business logic inside of dataContext methods? When I was
reading up on them, the only thing it looked likeyou could do was to create
methods that just called stored procs on the database. Am I wrong?

Well, you shouldn't put business logic inside any methods you create
on a data context. The context's purpose is to move data in and out
of a database, nothing more. A seperate business layer should be
built, which uses the DataContext and classes created for Linq to Sql.

Check out Csla.net if you want to build business objects using a
popular business object framework.