Index definitions and circular references.

[mrmoosehead]

Just interested to know how people are structuring apps in general when using Raven. 

I keep hitting circular reference problems that I wouldn't get with a SQL backing store.  The main reason being the index definitions. 

I have a Data project that holds all by database stuff that will get shared between apps. It seems logical to put index stuff in here. I have a fair few other projects with various reusable bits in, but I get stuck with the index definitions. 

It seems sensible to put these in code as they are part of the logic of the app(s) but they reference objects in libraries that need to reference the data project. These libraries use the indexes. therefore the libraries need to know about the indexes - hence the circular references. Even if i took the index definitions out of the data project, I still have the same issue. 

The only solution seems to be to have all the things that use the indexes and the index definitions in the same project - this doesn't feel right to me. 

I guess it begs the question - are the index definitions business logic that belongs with the app, or data definition stuff that belongs with the data?

[Daniel Lidström]

Just put everything in the same project. You can have modules defined as namespaces instead of assemblies. In general, you should only create a new assembly when you have requirements for physical separation (i.e. you don't want to deploy your tests with your code). Logical separation is usually better handled with namespaces. Patrick Smacchia has written a few articles on the subject worth checking out:

https://www.simple-talk.com/dotnet/.net-framework/partitioning-your-code-base-through-.net-assemblies-and-visual-studio-projects/

https://www.simple-talk.com/dotnet/.net-framework/defining-.net-components-with-namespaces/

Good luck!

[mrmoosehead]

Kind of the conclusion I had come to. Just wanted to know what other people thought. 

[Chris Marisic]

I don't know what you're doing but I've used ravendb for years and never once got into a circular reference situation. You are doing something very odd with your dependency graph.

I strongly disagree with put everything in 1 project.

[mrmoosehead]

ooh. that's a bit harsh. 

we have indexes defined in the data project that reference objects in a business logic layer. but a business logic layer needs to use the index. 

So we either a) define indexes in business layer, b) define indexes on raven server directly or c) have data / indexes/ business logic in a single project. 

I wouldn't put everything in one project either but many many small projects wasn't working for us. 

[Kijana Woodard]

Late to the thread. What's an example of an index used in business logic? Maybe I'm not understanding business vs data.

Indexes are the one thing I have considered separating from the rest of the project so they can be deployed explicitly and independently instead of automatically on app startup.

--
You received this message because you are subscribed to the Google Groups "ravendb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Chris Marisic]

We only execute IndexCreation in app start up in #IF DEBUG, it requires explicit admin intervention to execute in production.

[Chris Marisic]

Domain/Models project that has nothing but your models.

Reports project that has indexes, and the consumption of indexes.No usage of savechanges.

Services project that has data modification operation, uses savechanges.