Entities in separate project to implementation

Jan 24, 2015 at 7:58 AM
Hi,

I have my contracts (interfaces) in a separate assembly to their implementations (I think this is a fairly standard clean design technique). As I migrate to BrightstarDB, some of those contracts will become entities. However, I want the generated entity classes in my implementation assembly.

It seems the template does not currently accommodate this, or am I perhaps missing something? If not, could it support it? I'm tempted to hack around in the template (even hard-code for the purposes of getting my project up and running) but regardless I wanted to raise this as an issue.

The other possible solution I can think of is something like:
// in contracts
public interface ICustomer
{
}

// in implementation
[Entity]
public interface ICustomerEntity : ICustomer
{
}
Not sure I really like that either...

Any thoughts?

Thanks
Jan 24, 2015 at 8:07 AM
For the purposes of "get it to work so I can progress", I hacked the template so that it iterates over all projects in the entire solution:
class Helper {
    ... 
    private Solution _solution;

    public Helper(TextTransformation transformation) {
        ...
        _solution = DTE.Solution;
    }

    ...

    public IEnumerable<ProjectItem> GetCodeProjectItems() {
        foreach (Project project in _solution.Projects) {
            if (project == null || project.ProjectItems == null) {
                continue;
            }

            foreach (var pi in GetCodeProjectItems(project.ProjectItems)) {
                yield return pi;
            }
        }
    }
Kinda awful, but it works.
Jan 24, 2015 at 8:14 AM
Ugh, maybe I should just stop coding now. It's been a long day. Having thought about it more, I think the correct solution would be to keep BSDB completely out of my contracts layer:
// in contracts
public interface ICustomer
{
    // various members, many of which might be get-only, and all of which are completely focussed
    // on providing the the right interface to clients
}

// in implementation
[Entity]
public interface ICustomerEntity
{
    // similar members to ICustomer, but probably get/set and may have slightly different types
}

public partial class CustomerEntity : ICustomer
{
    // here I implement anything necessary for the customer entity to also implement ICustomer
}
That'll do for today - sorry for the spam. Now to watch some tennis...
Coordinator
Jan 27, 2015 at 8:53 AM
I think in general I would say that keeping implementation details like the use of B* out of the contracts makes sense. Although B*'s EF provides a form of data access layer, I think you actually want to layer that with your own DAL and have something like an CustomerRepository that mediates between the contract representation and the B* entity. We ended up doing this in one project, its a bit of extra work writing your contract interface implementations as wrappers around the B* entities, but it does effectively decouple everything from the contract layer above from the B* implementation.

Enjoy the tennis - looks like Murray/Kyrgios is going to be a close-run thing!