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

**Gregory A. Beamer** · Nov 13 '08, 04:15 PM

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

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:

Stop Making Sense

http://feeds.feedburner.com/GregoryBeamer

*************** *************** **************
| Think Outside the Box! |
*************** *************** **************
"Andy B" <a_borka@sbcglo bal.netwrote in message
news:eMcwqNCRJH A.5080@TK2MSFTN GP03.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** · Nov 13 '08, 05:05 PM

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

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" <NoSpamMgbworld @comcast.netNoS pamMwrote in message
news:C2B56120-D3EF-4B9F-9F07-C6298E5476AC@mi crosoft.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:

Stop Making Sense

http://feeds.feedburner.com/GregoryBeamer

>
*************** *************** **************
| Think Outside the Box! |
*************** *************** **************
"Andy B" <a_borka@sbcglo bal.netwrote in message
news:eMcwqNCRJH A.5080@TK2MSFTN GP03.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** · Nov 15 '08, 02:55 PM

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

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:

Stop Making Sense

http://feeds.feedburner.com/GregoryBeamer

*************** *************** **************
| Think Outside the Box! |
*************** *************** **************
"Andy B" <a_borka@sbcglo bal.netwrote in message
news:esmOvFbRJH A.588@TK2MSFTNG P06.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" <NoSpamMgbworld @comcast.netNoS pamMwrote in message
news:C2B56120-D3EF-4B9F-9F07-C6298E5476AC@mi crosoft.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_borka@sbcglo bal.netwrote in message
>news:eMcwqNCRJ HA.5080@TK2MSFT NGP03.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?
>>>
>>>
>>>

>>

>
>

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

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

Comment

Comment

Comment