How many database objects to put in an entity framework model?

[Andy B]

I have about 12 services that will be used on the website I am working on. A
few of them are News, Events, Venues (that work directly with Events),
Mailing lists and some others. Each one of these services will have some
classes and enums that are contained in a namespace of their own. When it
comes to the data access (entity framework), I need to know how to design
the model. Do I just put all of the database objects in a single model, or
do I split it up based on the service and put that entity model in the
rightful namespace? Can somebody give ideas?

[Gregory A. Beamer]

Splitting is fine as long as you can keep the objects unique. This can be
done by either naming them different or by placing them in another namespace
(you can do this with folders in the project to simplify). If you cannot do
one of the above (or both), it is often easier to make one big model. if you
have no dupes from serveice to service, there is no big deal.

A single big model looks daunting, but the objects only fill when requested,
so you are not trailing that much weight behind you if you go this route. It
is not optimal, for sure, but we are not all designing for Google like
performance, so it will probably be fine.

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

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
"Andy B" <a_*****@sbcglobal.netwrote in message
news:eM**************@TK2MSFTNGP03.phx.gbl...

>I have about 12 services that will be used on the website I am working on.
A few of them are News, Events, Venues (that work directly with Events),
Mailing lists and some others. Each one of these services will have some
classes and enums that are contained in a namespace of their own. When it
comes to the data access (entity framework), I need to know how to design
the model. Do I just put all of the database objects in a single model, or
do I split it up based on the service and put that entity model in the
rightful namespace? Can somebody give ideas?

[Andy B]

So, the question would be then, is it better to make multiple entity models
in different namespaces that target only a particular "service" or job than
to have 1 huge model hanging around? or is it better to have 1 huge model
that all code draws its data from?
"Gregory A. Beamer" <No************@comcast.netNoSpamMwrote in message
news:C2**********************************@microsof t.com...

Splitting is fine as long as you can keep the objects unique. This can be
done by either naming them different or by placing them in another
namespace (you can do this with folders in the project to simplify). If
you cannot do one of the above (or both), it is often easier to make one
big model. if you have no dupes from serveice to service, there is no big
deal.

A single big model looks daunting, but the objects only fill when
requested, so you are not trailing that much weight behind you if you go
this route. It is not optimal, for sure, but we are not all designing for
Google like performance, so it will probably be fine.

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

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
"Andy B" <a_*****@sbcglobal.netwrote in message
news:eM**************@TK2MSFTNGP03.phx.gbl...

>>I have about 12 services that will be used on the website I am working on.
A few of them are News, Events, Venues (that work directly with Events),
Mailing lists and some others. Each one of these services will have some
classes and enums that are contained in a namespace of their own. When it
comes to the data access (entity framework), I need to know how to design
the model. Do I just put all of the database objects in a single model, or
do I split it up based on the service and put that entity model in the
rightful namespace? Can somebody give ideas?

[Gregory A. Beamer]

You pretty much hit it on the nail and your application(s) will let you know
which is the better approach. If there is lots of shared data (same tables)
between services, a single model might be preferable, as you do not end up
with dupes. If you do dupe, you will have to separate out the models
(namespaces is the easiest option) or uniquely name entities. if many of
your entities are one to one maps, different names for objects is probably
not a good option, as it is confusing .... imagine this conversation;

When you use the X service, the weather object is name weather, but in the Y
service is is name wtr and in the Z service it is named wether.

Anything that you have to document like this shows a project not well
thought out. ;-)

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

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
"Andy B" <a_*****@sbcglobal.netwrote in message
news:es*************@TK2MSFTNGP06.phx.gbl...

So, the question would be then, is it better to make multiple entity
models in different namespaces that target only a particular "service" or
job than to have 1 huge model hanging around? or is it better to have 1
huge model that all code draws its data from?
"Gregory A. Beamer" <No************@comcast.netNoSpamMwrote in message
news:C2**********************************@microsof t.com...

>Splitting is fine as long as you can keep the objects unique. This can be
done by either naming them different or by placing them in another
namespace (you can do this with folders in the project to simplify). If
you cannot do one of the above (or both), it is often easier to make one
big model. if you have no dupes from serveice to service, there is no big
deal.

A single big model looks daunting, but the objects only fill when
requested, so you are not trailing that much weight behind you if you go
this route. It is not optimal, for sure, but we are not all designing for
Google like performance, so it will probably be fine.

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

Blog:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think Outside the Box! |
********************************************
"Andy B" <a_*****@sbcglobal.netwrote in message
news:eM**************@TK2MSFTNGP03.phx.gbl...

>>>I have about 12 services that will be used on the website I am working
on. A few of them are News, Events, Venues (that work directly with
Events), Mailing lists and some others. Each one of these services will
have some classes and enums that are contained in a namespace of their
own. When it comes to the data access (entity framework), I need to know
how to design the model. Do I just put all of the database objects in a
single model, or do I split it up based on the service and put that
entity model in the rightful namespace? Can somebody give ideas?