By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,152 Members | 2,039 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,152 IT Pros & Developers. It's quick & easy.

LINQ dataContext methods - should you put business logic there?

P: n/a
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?

Jun 27 '08 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On 13 Сав, 23:13, "Andy B" <a_bo...@sbcglobal.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.Services, 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...
Jun 27 '08 #2

P: n/a
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**********************************@m71g2000 hse.googlegroups.com...
On 13 Сав, 23:13, "Andy B" <a_bo...@sbcglobal.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.Services, 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...
Jun 27 '08 #3

P: n/a
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...@sbcglobal.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?

"DmitryPerets" <Dmitry.Per...@gmail.comwrote in message

news:2f**********************************@m71g2000 hse.googlegroups.com...
On 13 Сав, 23:13, "Andy B" <a_bo...@sbcglobal.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.Services, 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...
Jun 27 '08 #4

P: n/a
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**********************************@f63g2000 hsf.googlegroups.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...@sbcglobal.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?

"DmitryPerets" <Dmitry.Per...@gmail.comwrote in message

news:2f**********************************@m71g2000 hse.googlegroups.com...
On 13 Сав, 23:13, "Andy B" <a_bo...@sbcglobal.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.Services, 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...

Jun 27 '08 #5

P: n/a
On Apr 15, 7:17 am, "Andy B" <a_bo...@sbcglobal.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.

Jun 27 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.