Linq To SQL, WebServices, Websites - Planning it all

Several "parts" (a WinForms app for exmaple) of my project use a DAL that I coded based on L2SQL. I'd like to throw in several WebApps into the mix, but the issue is that the DAL "offers" much more data than the WebApps need. Way more.

Would it be OK if I wrapped the data that the websites need within a web-service, and instead of the website connecting d开发者_开发问答irectly to the DAL it would go through the web-service which in turn would access the DAL?

I feel like that would add a lot of overhead, but on the other hand, I definitely don't like the feeling of knowing that the WebApps have the "capabilities" of accessing much more data than they actually need.

Any input would be greatly appreciated. Thank you very much for the help.

---

You can either create web services, or add a repository layer that presents only the data that your applications require. A repository has the additional benefit of being a decoupling layer, making it easier to unit test your application (by providing a mock repository).

If you plan on eventually creating different frontends (say, a web UI and a WPF or Silverlight UI), then web services make a lot of sense, since they provide a common data foundation to build on, and can be accessed across tiers.

---

If your data access layer were pulling all data as IQueryable, then you would be able to query your DAL and drill down your db calls with more precision.

See the very brief blog entry I wrote on Repository and Service layers using Linq to SQL. My article is built around MVC but the concept of Repository and Service layers would work just fine with WebForms, WinForms, Web Services, etc.

Again, the key here is to have your Repository or your Dal return an object AsQueryable whereby you wait until the last possible moment to actually commit to requesting data.

Your structure would look something like this

Domain Layer
    Repository Layer (IQueryable)
        Service layer for Web App
            Website
        Service layer for Desktop App
            Desktop App
        Service layer for Web Services 
            Web Service

Inside your Service layer is where you customize the specific calls based on the application your developing for. This allows for greater security and configuration on a per-app basis while maintaining a complete repository that doesn't need to be modified until you swap out your ORM (if you ever decide you need to swap out your ORM)

---

There is nothing inherently wrong with having more than you need in this case. The entire .NET 4 Client Profile contains over 50MB of assemblies, classes, etc. I might use 5% of it in my entire career. That doesn't mean I don't appreciate having all of it available in case I need it.

If you plan to provide the DAL to developers that should not have access to portions of the data, write a wrapper or derive a new DAL. I would avoid the services route unless you're confident you can accommodate for the overhead.

---

Sounds like you are on the right track. If many applications are going to use the this data you gain a few advantages by having services with DTOs.

1. If the domain model changes, just the mapping to the DTO needs to change. You can isolate the consuming application from these changes.
2. Less data over the wire
3. You can isolate you applications from the implementation of the DAL.
4. You can expose different services (maybe different DTOs) for different applications if it is necessary to restrict what parts of the object model should be exposed.