A summary of my issues to better help me

I know I’ve asked a lot over the past year and a half, and maybe some things got lost due to my posting so often. Therefore, I’ve decided to summarize my issues in hopes that somebody will take the time to address each topic now that they are all in one place.

  1. Solution Structure

This is often a personal choice, and doesn’t really have anything to do with the end result. However, being able to organize things in a way that makes sense is important.

My problem is that I cannot seem to come to a decision on how I should split up the solution, if at all. In addition, naming these individual projects gives me problems. If I have a project named Venue.DomainModel, which follows the pattern Project.SingularSingular, then I want the rest to follow suit. For example, Venue.PersistenceEngine, Venue.LogicEngine, and Venue.UserInterface. There is a problem here though. The IDE likes to organize items alphabetically. This puts the service project between the domain and persistence. From a technical standpoint, this means absolutely nothing, but it irks me to no end. I want my projects to be listed in the order they are stacked in the architecture.

  1. I cannot decide which ORM to use.

Again, this is highly dependant on the size, complexity and needs of the target solution. I just can’t determine which one I should use. Each offers it’s own strong and weak points.

Linq2Sql is very easy, you can set individual namespaces for entities and contexts, as well as set the context name. This is nice for single project solutions, but is bad for those who want to use domain driven design as it is harder to customize.

Entity Framework (4) is a bit harder to setup. You have to drop the tables onto the canvas and then adjust the getter and setter access levels for various properties. It is nice though as once that is done, all you need to code is the domain specific partial.

Using either L2S or EF also means that your mapping (typically) will be in the same project as your entities. As EF is now persistence ignorant, this shouldn’t be a problem, but the same cannot be said for L2s.

NHibernate/FluentNHibernate is extremely flexible. Entities can be coded in one project, with mapping in another. One downside is that you have code the entities yourself. If you have an entity with nearly one hundred fields that need logic behind them, your in for a big chunk of coding time. Another downside is that there are a lot of third party external dependancies one will need to reference. Often times, these libraries conflict with other libraries.

  1. Circular references

I am really hung up on this one. In one test solution, I have my entities in their own project. These entities need to test certain things, and I wish to use the Specification pattern for it. I don’t want to put these spec classes in the domain project, so I made an infrastructure project to contain them. They include simple things like IsNullEmptyOrWhiteSpace() or IsInRange(). They also include some more complex things like UserCanEditPost(Post post). Now, this one needs to reference the entity project obviously. This won’t work and so far, I’ve not been able to clean it up.

  1. Remants from the above.

If I decide my application is NOT suited for DDD, then I am faced with further decisions. Not using DDD leaves the “entities” in a rather plain state (anemic as some call it), forcing business logic into the service layer. Now, with such an anemic model, begin to wonder why I need ViewModels. It should be safe now to pass around the “entities” (quoted because they aren’t really entities at this point), including into views, since the service layer will be validating and fixing them up anyway before committing to the backend.

If I use either L2S or EF, I am not sure I see a real point in the repository pattern. The contexts provided by both are, in themselves, a repository implementation. The most I could see doing here is writing some extension method classes that tweak IQueryables.

So all in all, I just need some guidance and advice. Possibly somebody could talk with me more privately about the exact nature of this application.

Thanks in advance to anybody who may help with this.