I'm looking for some best practices on how to setup a three tier application design with a SharePoint Service Applications.
A case example: suppose I have customers, each customer has a set of addresses and contacts. Those aren't stored in SharePoint, but there stored in a seperate database which is only accessible via my CustomerService custom service application. I need some basic functionality like CRUD and it will have some detail forms, nothing out of the ordinary.
Should I use EF of Linq? I find EF more appealing, but I think the 4.x versions are out of the question since SharePoint doesn't support Framework 4.
Suppose I consider my EF/Linq model to be my data layer. The Service Application will be the business layer and the interface will consist of webparts or application pages. If I keep my entities in the EF/Linq class and return those from the BLL, I need to also reference that data layer in my interface layer, which seems tricky. The app is to be multi tenant, so I cannot risk any data getting passed the business layer without being properly filtered first. So I'd rather not incude the data layer at all to prevent trouble.
I've seen some nice examples in which a t4 script creates POCO objects for an EF layer. I could make those live in a seperate assembly and only reference that assembly in my GUI. That way I wouldn't have to create a second entity object and mappers and stuff, and still be safe about my database data.
How about related stuff? Suppose I want to show the customers addresses on one screen and the contacts on another. With a more direct reference to the EF layer, I could just use the lazy loading to fetch the related records on binding / loading. When I don't have that; I need seperate methods for literally anything I need to get out of or put into the database. That's a lot of extra work. Any other options I'm missing?
I'm hoping you guys can provide me with some pointers in the right direction on these design issues. Thanks.