Develop Reference

Architecture for new ASP.Net MVC Project

I am at the start of a new project but I am not sure about some architectural choices.
I was hoping that you guys could share me your vision on this.
The client wants an internal website to manage their clients, projects, stock/products,…
Next to this they also want a website for their clients where they can view the products and order them. So for the external website only a small part of the db will be queried while the internal website will be much bigger.
At first I was thinking about using a WCF service for all businesslogic and repository.
But now I am not sure since I know that only a small portion of the actual logic will be used for the external part.
Using WCF as an extra layer always brings a shitload of extra work and complexity to the project. Is it better to just reference the business/repository layer in both website projects or make use of webAPI in the external website?
Really I need to hear some other opinions before I decide what to do.

There is nothing inherently wrong with going WCF, business layer assembly, or Web API. All have pluses and minuses.
WCF would make the most sense if you may someday have a many different clients needing access to the data/business logic and these clients may need to communicate differently (i.e. HTTP, MSMQ, full duplex, etc.)
Business Layer assembly would make sense if you are quite sure the data/business logic will not need to be accessed by clients other than the 2 web applications you are developing. That's not to say you're boxed in doing this though either. You could always start here and later remove reference to the assembly, encapsulate access to the assembly within WCF or Web API, and then reference WCF or Web API from web applications.
Web API is a good choice for several reasons. It provides the ability for many different clients access to the data/business logic without all of the overhead that comes with WCF. Additionally, if you have non .NET clients you need not worry about some of the tweaks you would have to potentially make on WCF bindings. You can also take advantage of some of what MVC provides you within the Web API such as model binding and validation.

Exposing DataAccessLayer in WCF services

I've builded an N-Tier application for CRUD operation with 3rd party libraries.
This is my app design packaging:
List item
Core - with domain models and entities.
DataAccessLayer - with 3rd party libs NHibernate and IOC container Ninject
Ui - Wpf app or Asp.net MVC app
Now i want to separate UI from DAL, exposing my CRUD repositories via WCF Tcp services.
This choice was made for client-server design:
Server: WCF -> DAL with all 3rd party softwares for Database Connection (a lot of driver are very bigs and expensive to install in 100+ clients).
Client: My WPF or SilverLight UI.
I've builded MVC and WebForms APP, a lot of people think that this is a better solution!
But with wpf I have many possibilities to play with graphics and development is faster for me.
All my repositories extending an Interface (for Dependency Injection with Ninject) and i want to add this to my WCF services without create others Interfaces. A lot of my repo's function returning list of NHibernate objects, how to add Attribute "DataMember" to a non WCF project?
But my simple question is, "WHAT IS THE BEST WAY OF DOING THIS,maintaining a good design?"
Thanks for patience!

Ideally you want all of your business logic in the WCF service with the UI as dumb as possible. That way you can create any number of User Interfaces (WPF, Silverlight, MVC, iPhone even) and they are all small and simple with all the common logic in the WCF.
You need to keep things as loosely coupled as possible so following on from that you don't want to pass database things to the front end. Instead you want to send POCOs or DTOs to the front-end that do just enough for the job. Avoid sending a whole database item to the front-end because ideally your front-end should have no knowledge of what database is being used or how it is structured.
As far as your UI is concerned ONLY the WCF contract is important and the DTOs etc. The WCF should be split into several different layers (or tiers), this depends on your approach but you could have facade, business logic, data access layers (do some research into what fits your situation best). You might want to use repository pattern etc, etc, but that will be in the WCF service and the UI will have no knowledge of what is happening in this "Black box".
Ultimately what you want is for all the components to fit together with the least amount of "coupling" where you should be able to swap one component out for another without everything else "depending" on it and breaking.
This is a DEEP subject and I have scratched the surface but hopefully get your thoughts on the right track!

WebAPI and MVC on separate Machines

I have both a design question along with an overall question of the way WebAPI works.
We have an Internal Website that houses many applications ( a seperate MVC Area for each application). We then have sectioned out the DAL Logic into libraries that are front ended by Web Service calls. The Models/Repositories will call to CRUD things inside several databases (some internal, some third party). So It looks like this
UI -> Model-> Repository -> WebServices -> DB.
This was originally done because we needed to be able to access multiple data access points and funnel them back to the Internal Website for various applications and it seemed like a good way to abstract out all the logic so that the Web Application only focuses on the View end. This pattern has proven to be good for seperation of concerns, but now we are looking into making this available to more than just .NET applications/clients and that points me to begin to look at WebAPI.
Here are my questions:
My main question is, knowing that the Web Services are all done in WCF ( contract based), how hard would it be to convert this to using WebAPI keeping in mind that we wish to make sure the WebAPI webservice is on a separate server from the UI.
Is there any way to set up WebAPI to have contracts and still use the HTTP verbs?
If i am remotely accessing the WebAPI web service via an MVC application on another server and another solution, is there any way to still get that strongly typed objects that you get when you consume a WCF contract?
What are people's thoughts on this design pattern?

application completely SOA?

Is it wise to build a large application entirely based off SOA? Or just some portions? User account logins, accounting, gis mapping, sales, etc?
In other words, would it be wise to build a GUI to such an application in HTML & Javascript which does all it's exchanges via ajax to .NET web services on the back-end?
I can't see it worth loosing all the .net .aspx functionality such as forms authentication, view state, etc. But my co-worker is saying if we are going to go SOA there is no need for .NET on the front end. But i think there should be some sort of balance. Where do you draw the line? Should all calls to the database go through the web services?

I just want to say that "with SOA we’re building for change, while with Traditional systems engineering, we’re building for stability."
The problem with stability, of course, is, it only takes the business so far — if the organization requires business agility, then they’re much better off implementing SOA.
So, It solely depends on what you want to achieve, you are the one who should draw the boundary.
I read it in article on SOA few days back as I'm too working on SOA.
EDIT:
Meanwhile I came across this article and thought of sharing with you.
The video quite explains the current scenario of SOA and its views by different people.

I'm getting the words of the song 'If I had a hammer' coming to mind. SOA is an architectural approach to develop software as a series of services. In my opinion this is best for systems that have less than immediate latency and limited bandwidth, and high cost in access etc (these are all obviously highly subjective). You don't need full SOA just get loose couping between components which I would argue is a good goal to achieve.
DB calls can go through a service, take ADO.NET data services for example however you really have to weigh up with what the service is to provide. Take caching. A decent approach to SOA will consider that data is may need to be cached to reduce service load. So can your data be stale in the UI? Are you allowing that use case? Is right for login info to be stale (a rough example I know but possibly something that may need to be addressed).
All in all - it depends. I think some things lend themselves to SOA very well. If you take a DDD approach then the services that represent Domains would probably do so. In this way your UI talks to domain services and not rows in table as the DB is abstracted behind domain services.
Don't use one methodology to solve all problems.
See this SO question too

It's a service oriented architecture, not a service exclusive architecture.
Presentation logic and plumbing have to live somewhere; it all depends on where it makes the most sense for it to live.
For example, let's say you have a UI component that relies on a highly chatty but efficient set of calls to a database to generate a complex analysis of something (take your pick). If your web browser is making all those calls, you introduce massive network latency and concurrency issues. If a web service makes all those calls, you are potentially putting presentation logic into it to format that result.
If you are using Session state (or web services period), you are essentially using ASP.Net anyway. Try uninstalling it and see if your web services still run.
If presentation logic needs to live on the server side, it is better for it to live within a framework intended for presentation rather than a web service, IMO. If you haven't looked at MVC 2, do so. It makes it incredibly easy to set up an application that melds browser and server UI support (for example, jQuery validator controls backed by server-side validation).
Conversely, the web browser provides an expressive platform. Assuming browser support and team knowledge, the AJAX/SOA architecture you describe is a good one. I'm using it more and more and trying to make my server pages cleaner and simpler but I have no plans to exclude ASP.Net from my toolkit any time soon.

Client implementation should be completely disconnected from the back end web service in a SOA. The service should be able to be consumed by ANY client. If you are using .NET on the back end and front end because they can be coded to directly communicate, then you are missing the point, because now they are tightly coupled and what you have now is a stove pipe application. The client should have no idea how the server side is implemented -- shouldn't matter if the back-end web service is built using .NET, Java, or whatever.
In a true SOA, you should be able to search for services in the services repository, perhaps tie the outputs in with other services or use XSLT to create alternative outputs that weren't necessarily considered when the original service was built, and consume it in a standard way in any client on the front end.
It sounds like what you're really asking is how to build a single application. The point of a SOA is to provide standard data sets through re-usable interfaces, that have no specific application or implementation in mind. To start out building a single application with the entire back-end comprised of SOA services would be a huge undertaking. In MY mind, each back-end service should be built because of it's intrinsic value all on it's own and be provided to the entire SOA "domain". Then when you or I decide to make a client that does X, Y, and Z, we can just go find those capabilities in the SOA and injest them.

webservices with repository pattern in c# and WCF?

Can anyone confirm the best way to integrate the repository pattern with webservices.... Well actually i have my repository patter working now in c#. I have 3 projects, DataAccess, Services and my presentation layer.
Problem is my presentation layer is a number of things... I have a ASP.NET MVC site, I have an WPF application and we are about to create another site + an external company needs access to our repository also.
Currently i have just added the services layer as reference to each of the sites... But is not the normal way to provide data access via web services? (WCF) - if this is the case will this break the services layer? or should i convert the services layer to a web service?
Anybody know what the PROS and CONS are of this, speed??

I think I understand your dilemma. If I understand correctly then your services layer consists of pure fabrications. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design).
If I assume correctly above, then your services layer should not be impacted at all by the introduction of WCF. WCF is essentially an additional presentation layer that provides interoperability, sitting between your UI presentation layer and any business logic layers. So your WCF services would then call your services layer, which may access repositories as needed.
WCF provides a high degree of interoperability so I think it is an excellent choice. I would use basicHttp bindings though, if you intend to interop with different programming languages as this is the most flexible. Don't worry about the speed. There are plenty of solutions out there to mitigate any bottlenecks that result due to WCF.
Good luck, and let me know if I can help in any other way.

Well first - not all callers have to use the same repository API; this is especially true of an external company.
WCF is interface based. This means that if you need to re-use some logic code, it is possible to use IoC/DI to inject WCF rather than a DAL (but using the same interface) - by using assembly sharing. It sounds like this is what you are doing. This works in many cases, but not all; fundamentally web-service based APIs often need to be designed differently in order to be optimal. It also isn't 100% pure from an SOA viewpoint, but it gets the job done, and allows more intelligent domain entities, so in an intranet (etc) scenario it is (IMO) perfectly reasonable.
An external caller would typically just use the wsdl/mex-based APIs (rather than assembly sharing), but anything is possible...

Maybe webservices are not the best way, if i have full access to the service assembly then i suppose it always better to assembly share the services layer with my applications.
My applications do similar things, but they all need to access the service layer - well the business logic and get back information...
In this case - its always preferable to use assembly sharing with the service layer rather than provide a WCF Web service using HTTP protocol or using TCP on wcf - for example?
Thanks again

Whether to share your Service/API assemblies with your client applications is fairly subjective. If you are a full Microsoft shop, and use .NET for your entire application stack, then I would say sharing the API is a great way to gain code reuse (you have to be careful how you design your API so you don't bleed domain concerns, like repositories, into your presentation.) If you don't have any plans to migrate your client applications to other platforms (i.e. you plan to stay on .NET for the foreseeable future), then I think its perfectly acceptable to share your Service/API assemblies (and even then, in a multi-platform client environment, sharing Service/API with .NET clients should still be acceptable.) There is always a trade off between the 'architecturally ideal' and the 'practical and achievable within budget'. You can spend a LOT of time, money, and effort trying to achieve the architecturally ideal, when the gap between that and the practical often isn't really that much. The choice NOT to share the API and essentially recreate it to maintain "correct" SOA, consuming only the contract, can actually increase work and introduce maintenance hassles that quite possibly are not worth it for your particular project at this particular time. Given that you are already generally 'service-oriented', if at a future point in time you need the benefit that contract-only consumption on the client can offer, then your already set to go there. But don't push too far too soon.
Given your needs, from what I have been able to glean from these posts so far, I think your on the right track from your services down too. A repository (a la Evans, DDD) is definitely a domain concern, and as such, you really shouldn't have to worry about it from the perspective of your presentation layer. You services are the gateway to your domain, which is the home of your business logic. Repositories are just a support facility that helps you achieve domain isolation from a data store (they are glorified collections really, and to be quite frank...they can be a bit of a pain in a dynamic and complex domain. Simple data mappers, (Fowler, PofEAA) are often a lot easier to deal with and less complex in the long run, and allow more adaptable behavior around your data retrieval logic to be centralized in your domain services.) Aside from heavy use of AJAX calls to REST Services, if you expose adequate Services/API around your domain, that is the only thing that your clients should have worry about. Wrap up all the rest of your business logic entirely within the confines of your domain, and keep your clients as light weight as possible and abstracted from concepts like 'Repository' or 'Data Mapper' and whatnot.
In my experience, the only non-service or API concept that needs to be shared across the Client-to-Domain boundary is Context...and it can be notoriously difficult to cross that boundary in a service-oriented application.