Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

share|improve this question
add comment

1 Answer 1

Have you considered just using the OOTB Business Connectivity Services? If you have enterprise, you can simply set up connections to these databases and create some very rich applications. If you only have Standard, then you can still do a great deal with connecting to these external sources and creating them like lists in your environment, then you can work with these lists like you would regular SharePoint lists, creating pages and mashups using this data. If the data is in a database that is using SQL, then you have all of the tools OOTB with no need to build application definitions or write any code.

share|improve this answer
    
Hello Lori, thanks for your suggestion. I find BCS perfectly capable of handling regular lists with normal flat data, but we're talking a full DB model with lots of relations and stuff here, not something SharePoint / BCS is real good at if you ask me. I think using BCS is going to give me more trouble then it'll actually help. –  Jasper Jul 1 '11 at 6:34
    
By the way, I am going to use BCS to get the data from my database to SharePoint; but mainly for being able to link SharePoint data like documents and stuff to a customer (for instance) via a BCS column. –  Jasper Jul 1 '11 at 6:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.