how to build modular software using linq

[Guest]

I have a database with 3 tables

users
groups
threads

I want to build my software in a modular way, so that the module groups will
manage everything about groups and the module threads will manage everything
about threads.

Using linq I can create
groups.dbml
that need to contain user and groups
threads.dbml
that need to contain user and threads

In this case I'll have 2 user classes that I'll need to maintain...

Is there any way to inherit a dbml from another one or have partial dbmls?

Simone

 

[Cor Ligthert [MVP]]

Simone,

Not direct using an anonymous class (var or dim), and with an other approach
you are soon in a non strongly typed solution.

Be aware that Linq is a Query tool with extensions for SQL server, Linq is
not primary only a database tool.

Just my opinion before I get comments.

Cor

 

[Guest]

The problem is that if you use linq to query the dbml you need to have all
the tables you need on every dbml so you need to maintain multiple dbml if
you need one table on every module...

So a kind of partial or inherit system should be present on the dbml
designer...

Simone

 

[Cowboy \(Gregory A. Beamer\)]

The problem is that if you use linq to query the dbml you need to have all
the tables you need on every dbml so you need to maintain multiple dbml if
you need one table on every module...

If you are ultimately crafting objects that span tables, this is true. You
also have to look at the goal of your DAL, as there is give and take for
every software problem. Be careful when you look at the problem through a
particular solution domain, as you might become a hammer seeking nails.

You can effectively set up a single table DBML and query it. It will require
more contexts and more hits on the database. This can affect scale in a
negative way, although Moore's law is on our side (not saying we design for
Moore's law). But it can also greatly improve maintainability, as we can use
a generic DAL (meaning using generics).

So the question is "what is your goal?"

1. Scalability
2. Availability
3. Maintainability
4. Performance
5. Security

You can say "all of the above", but remember that you will have to
compromise and you will find that the goal is not equal parts of all of the
above, but a weighted list. Then the compromise comes in.

My point is you are stuck in the problem and it may be harboring you from
finding a proper solution.

So a kind of partial or inherit system should be present on the dbml
designer...

Possibly, but we are dealing with trade offs and perceptions here.

First, as mentioned, is the problem may be clouding the solution. Shifting
focus might yield that partial/inherit systems are not the only solution and
may, also, not be the proper solution ("best" solution).

Second, that the problem may not be hitting very many people. While
Microsoft should do things right, the definition of "right" is very loose.
In addition, they make money by hitting the 80% rather than the 20%. Until
enough people are impacted by the problem, or better yet "see it as a
problem", it is unlikely to be included.

Third, that the problem might be less pressing than other problems. This
also relates to 80-20, but from the other end of the spectrum.

Summary:
Based on what I have read about your issues, I am not sure LINQ should be
used to build a DAL in your case. I am not overly thrilled about LINQ as a
DAL anyway (although I have softened my hard line stance and blogged about
my reasoning). It sounds like you need custom classes. You may still employ
LINQ at some levels, but it sure sounds like you have fallen out of the
"drag and drop box".

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************

 

[William Stacey [C# MVP]]

Not sure I understand. If you only need 1 table, then you can have a dbml
with 1 table. What am I missing?
--wjs

 

[Cor Ligthert[MVP]]

Simone

Yes, and?

Cor

The problem is that if you use linq to query the dbml you need to have all
the tables you need on every dbml so you need to maintain multiple dbml if
you need one table on every module...

So a kind of partial or inherit system should be present on the dbml
designer...

Simone

 

[smnbss]

Thanks a lot

Simone

If you are ultimately crafting objects that span tables, this is true. You
also have to look at the goal of your DAL, as there is give and take for
every software problem. Be careful when you look at the problem through a
particular solution domain, as you might become a hammer seeking nails.

You can effectively set up a single table DBML and query it. It will
require more contexts and more hits on the database. This can affect scale
in a negative way, although Moore's law is on our side (not saying we
design for Moore's law). But it can also greatly improve maintainability,
as we can use a generic DAL (meaning using generics).

So the question is "what is your goal?"

1. Scalability
2. Availability
3. Maintainability
4. Performance
5. Security

You can say "all of the above", but remember that you will have to
compromise and you will find that the goal is not equal parts of all of
the above, but a weighted list. Then the compromise comes in.

My point is you are stuck in the problem and it may be harboring you from
finding a proper solution.


Possibly, but we are dealing with trade offs and perceptions here.

First, as mentioned, is the problem may be clouding the solution. Shifting
focus might yield that partial/inherit systems are not the only solution
and may, also, not be the proper solution ("best" solution).

Second, that the problem may not be hitting very many people. While
Microsoft should do things right, the definition of "right" is very loose.
In addition, they make money by hitting the 80% rather than the 20%. Until
enough people are impacted by the problem, or better yet "see it as a
problem", it is unlikely to be included.

Third, that the problem might be less pressing than other problems. This
also relates to 80-20, but from the other end of the spectrum.

Summary:
Based on what I have read about your issues, I am not sure LINQ should be
used to build a DAL in your case. I am not overly thrilled about LINQ as a
DAL anyway (although I have softened my hard line stance and blogged about
my reasoning). It sounds like you need custom classes. You may still
employ LINQ at some levels, but it sure sounds like you have fallen out of
the "drag and drop box".

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************