We Keep Coding

.NET SOA architecture

I just started working as an intern and have few architecture understanding question.
I apologize this is not the correct place to ask this question.
The application designed here has 2 parts, one UI and one API. The UI App is written on Angular while the API App is designed using
C# and .NET Core. The Angular app is making API calls to the API App to fetch data, insert etc. In the API everything is done using dependency injection
which is defined in start up class etc. and if I understand correctly I don't see any other design patterns being used here etc.
Now what I want to know here what will we call this architecture where API calls for data are made from Angular. Since services are defined in this API project can we call the API project a service oriented architecture. My last question is since I don't see any design pattern used here, is this common practice in .NET core projects to just use dependency injection or if we can use some other patterns here as well.
Sorry again if my question is vague or does not belong here.

As you only have two parts, an API (backend) and a Angular frontend, this would probably be more in the realm of a standard layered architecture (Figure 10-2 in Fundementals of Software Architecture by Neal Ford shows the arrangement you are talking about). It's a variant in that the frontend and backend are decoupled, but probably not enough to call it a Service Oriented Architecture.
In an SOA, you would be likely to see several backend services not just one - you would have multiple distinct APIs separately deployed with one or more front end UIs calling on them. In an SOA the API itself is the service... not the individual services defined in a single dotnet project.
The design pattern question doesn't make too much sense to me here... design patterns are simply useful approaches to recurring themes in coding, they are used really on a case by case basis as and when the need arises. For example, in a service oriented architecture, it's probably not uncommon to see an API gateway ( facade design pattern ).
I certainly wouldn't call it common practice not to use design patterns... at least I hope not! I rarely start a project by forcing design patterns in early on, but certainly as the code grows and is refactored, opportunities to use (and benefit from) design patterns always emerge.

How to make the framework and the dependent applications loosely coupled?

I have a specific case and I want to know the best practice way to handle it.
I make a specific .NET framework (web application). This web application acts like a platform or framework to many other web applications through the following methodology :
We create our dependent web applications (classes for the project business, rdlc reports) in a separate solutions then build them.
After that we add references to the resulted dll in the framework.
And create set of user controls (one for each dependent web application) and put them in a folder in the framework it self.
It works fine but any modification to a specific user control or any modification to any one of the dependent web applications. We have to add the references again and publish the whole framework !!
What I want to do is make those different web applications and the framework loosely coupled. So I could publish the framework one and only one and any modifications to the user controls or the different web applications just publish the updated part rather than the whole framework .
How to refactor my code so I can do this?
The most important thing is :
Never publish the whole framework if the change in any dependent application, just publish the updated part belongs to this application .

If loose coupling is what you are after, develop your "framework(web application)" to function as a WCF web service. Your client applications will pass requests to your web services and receive standard responses in the form of predefined objects.
If you take this route, I recommend that you implement an additional step: Do not use the objects passed to your client applications directly in your client code. Instead, create versions of these web service objects local to each client application and upon receiving your web service response objects, map them to their local counterparts. I tend to implement this with a facade project in my client solution. The facade handles all calls to my various web services, and does the mapping between client and service objects automatically with each call. It is very convenient.
The reason for this is that the day that you decide to modify the objects that your web service serves, you only have to change the mapping algorithms in your client applications... the internal code of each client solution remains unchanged. Do not underestimate how much work this can save you!
Developing WCF web services is quite a large subject. If you are interested, a book that I recommend is Programming WCF Services. It offers a pretty good introduction to WCF development for those who come from a .NET background.

I totally agree with levib, but I also have some tips:
As an alternative to WCF (with its crazy configuration needs), I would recommend ServiceStack. Like WCF it lets you receive requests and return responses in the form of predefined objects, but with NO code generation and minimal configuration. It supports all kinds of response formats, such as JSON, XML, JSV and CSV. This makes it much easier to consume from f.ex. JavaScript and even mobile apps. It even has binaries for MonoTouch and Mono for Android! It is also highly testable and blazing fast!
A great tool for the mapping part of your code is AutoMapper, it lets you set up all your mappings in a single place and map from one object type to another by calling a simple method.
Check them out! :)

Decades of experience says: avoid the framework and you won't have a problem to solve.
Frameworks evolve like cancer. The road to hell is paved with good intentions, and a good portion of those good intentions are embodied in a colossal tumour of a framework all in the name of potential re-use that never really happens.
Get some experience and knowledge when it comes to OO and design, and you'll find endless solutions to your technical problem, such as facades, and mementos, and what have you, but they are not solutions to your real problem.
Another thing, if you are using MS technology, don't bother with anything beyond what .NET offers. Stick with what the MS gods offer because as soon as you digress and become committed to some inhouse framework, your days are numbered.

in .net, what programming model would be good for prototyping, but then reusable for production (for business logic/data access layers)

In .NET land what would be a good approach for quick prototyping of a concept (i.e. development just on my PC) that could then be extended out to product (users across LAN/WAN), BUT in a fashion that the model/business logic code and data access layer code can be used as is?
One thought for example I had as to do:
(a) WinForms with business logic and Entity Framework layer to SQL Server Express on my PC, then
(b) Go then to ASP.net (using the business logic / data library) with SQL Server/IIS
Any comments? Other suggestions?

I would recommend trying a layered approach:
put your entity data model and validation classes into a separate assembly
put additional business logic into a separate business logic assembly
put your services (WCF or WCF Data Services) into their own assembly
All those base layers are pretty much independent of what you choose as the UI frontend technology. You can make choices here (e.g. Linq-to-SQL vs. Entity Framework for your data access; do you need a WCF-based service layer, or does your app use direct DB access?) more or less independent of what you put on top of that for the UI layer.
And on top of those base assemblies:
create your UI either as Winforms app, or as an ASP.NET (Webforms or MVC) web app (or both)
If you have layers and if you architect them well, you can reuse a large portion of your code and business rules.
Try to put only stuff that's specific for each UI technology (Winforms vs. ASP.NET) into those frontend presentation assemblies. Keep all the common business rules, validation rules, access and service layers separate.
And again: it seems you believe that "going ASP.NET" excludes using WCF/WCF Data Services - not at all ! You can easily use data from a WCF service in an ASP.NET app. You're not losing anything by layering your business and services layers - those can be easily reused in both Winforms and ASP.NET apps!

A few comments:
Prototyping as an approach to developing production quality software can be problematic, as the very nature of prototyping can mean that the software and design quality are not that great. Prototypes are not meant to be great quality by definition.
If the goals are to get some feedback from the intended customer\user during the early stages, it can often be a good idea to not prototype full vertical slices (e.g. UI -> Business -> DB), but work with UI mockups which can be used to explore ideas with users. The mockup is flexible and easy to change, but is not fully functional e.g. does not have business logic or persistence. This approach allows users to get some idea of functionality and be involved in the design and requirements gathering process. It will be quick to change the mocks as requirements change, especially as there is no business logic or database code that has to be changed with it. An example of a UI mocking tool is Balsamiq:
http://www.balsamiq.com/
If one of the overall goals of prototyping is to investigate and explore different technology choices, these can be done in isolation of UI mockups, and in a more abstract fashion i.e. pure technology investigation rather than geared at delivering the exact needs of a prototype which can be changing massively. The UI mockups may change a lot via user feedback, so having technology investigation as a different activity can make this process simpler i.e. there is less coupling as things will change a lot during the early discovery phase, and having to change the "backend" constantly because UI ideas are developing so rapidly, will slow you down.
In terms of speeding up the pace of software development, leverage third party libraries. If you are using a database for persistence, look at ORM solutions which could massively reduce the work needed to develop a data access layer e.g. nHibernate. Depending on what UI technology you use, look at third party control libraries.
In the industry, the approach that has very much replaced prototype driven development over the years is: Agile. It seeks to tackle the changing needs of users head-on by always striving to deliver features, but has a focus on developing high quality software through techniques such as TDD.

Need an example of a "Good Line of Business Application" for .NET that uses ORM

I'm trying to move toward TDD, ORM, Mocking, ect. I need a good example of a line of business app that uses an ORM preferably NHibernate.
It has to be open source and use the repository pattern.
I learn best by example, I have played around with the repository pattern and unit of work pattern but not in any meaningful applications.
I'm familiar with IoC (I use unity), WCF, Workflow Foundation, WPF, Smart Client Software Factory, Webclient Software Factory, ect.
I've learned all the "basics" (they are pretty advanced principals to be called basics, IMO) I just can't seem to put it all together.
The applications we write follow all "best practices" as far as architecture, we have a business logic layer, data access layer, MVP, MVVP, MVC, ect. but there is never any code in our BLL's besides
return dal.GetBlahBlahBlah();
I have to ask myself where is all my business logic???
Probably 95% of our data access is through stored procedures and I have to assume that its all if the database. Some of these SP's are huge and have lots and lots of if statements, case statement, and the occasional cursor.
As mentioned above I know how to use all of these cool technologies but it seems like the only thing I'm using them for is to make a really, really overcomplicated, overly architecture'd reporting tool for sql server.
If ALT.NET is the better way, if having all of your business logic in the code is the better way, there has to be an open source application out there that puts it all together in all the right ways

I haven't come across any LOB applications but I have heard that Cuyahoa is an excellent example of how to use NHibernate.
I am familiar with the code in Suteki Shop, an e-commerce platform using ASP.Net MVC and Linq-To-Sql which is active at the moment and being re-factored very well and should provide you with some insight in to what you're attempting.
Penultimately, there is Rob Conery's MVC StoreFront. Rob is the master of screencasts and presents a great insight in to learning TDD.
My final link is summer of nhibernate another series of screencasts this time specifically on using NHibernate

How would you architect a desktop application in C# 3.0

I've created a simple desktop application in C# 3.0 to learn some C#, wpf and .Net 3.5.
My application essentially reads data from a csv file and stores it in a SQL server CE database. I use sqlmetal to generate the ORM code for the database.
My first iteration of this app is ugly as hell and I'm in the process of refactoring it.
Which brings me to my question. How would you architect a desktop database app in C#?
What are the best practices?
Do you create a Database Abstraction Layer (DAL) which uses the sqlmetal generated code? Or is the generated code enough of an abstraction?
If you use DAL pattern, do you make it a singleton or a static member?
Do you use the View-Model-ModelView pattern with the DAL pattern?
Apologies if this seems like a long open ended question, but I have been giving this a lot of thought recently.
I see a lot of examples on how to architect an enterprise n-tier app in C# but not that many on architecting standalone desktop apps.

I would start with the Composite Application Guidance for WPF (cough PRISM cough) from Microsoft's P&P team. With the download comes a great reference application that is the starting point for most of my WPF development today.
The DotNetRocks crew just interviewed Glenn Block and Brian Noyes about this if you're interested in hearing more from them.
Even better, Prism is not nearly as heavy as the CAB was, if you're familiar at all with that from the WinForms days.

The answer is "it depends" as always.
A few things to think about:
You may want to make this fat client app a web app (for example) at some point. If so, you should be sure to keep separation between the business layer (and below) and the presentation. The simplest way to do this is to be sure all calls to the business logic go through an interface of some kind. A more complex way is to implement a full MVC setup.
Another thing you may consider is making the data access layer independent of the business logic and user interface. By this I mean that all calls from business logic into the DAL should be generic "get me this data" rather than "get me this data from SQL" or even worse "run this SQL statement". In this way, you can replace your DAL with one that accesses a different database, XML files, or even something icky like flat files.
In short, separation of concerns. This allows you to grow in the future by adding a different UI, segmenting all three areas into their own tier, or changing the relevant technology.

Before architecting anything you should define requirements for your app.
It's a common error of beginner developers - starting writing code ahead of thinking about how it would perform. My advice will be to try to describe some feature of you application. It will help you to feel how it should be implemented.
As for useful learning resources I would highly recommend you to take a look at CompositeWPF it's a project designed specifically to teach developers best practices of desktop app development.

I'd start with Jeremy Miller's Build Your Own Cab series.
I was an early CAB adopter. I learned a lot from digging into that technology and reading all the .NET blogs about application architecture.
But recently I had a chance to start a new project, and instead of using CAB I went with StructureMap & NHibernate and borrowed some of the patterns that Jeremy uses (in particular, his way of handling event aggregation). The result was a really simplified, hand-tooled framework that does everything I need and I love working with it.
As to the specifics of your question: I use a Repository for data access. I initially wrote some ADO.NET code and used data readers and mapped my objects. But that got old real fast, so I grabbed NHibernate and was really pleased. The repositories use NHibernate for data access, and my data access needs are pretty simple in this particular app.
I have a service layer (exposed via WCF, Duplex channels) that utilizes the repositories. My app is basically client-server with real time updating (and I know your question was just about clients, but I would use the same technologies and patterns). O
n the client side I utilize MVP with StructureMap for IoC and some very simple event aggregation strategies for cross-class communications. I code to interfaces for just about everything. The only other thing I did was borrow from the CAB the idea of a flexible "Workspace" for dynamically displaying views. I wrote my own Workspace interface though and implemented my own DeckWorkspace and TableWorkspace for use in my app (these were really simple things to write).
A lot of my decisions in this most recent application were the result of experience and pain I felt using other frameworks and tools. I made different decisions this time around. Maybe the only way to really understand how to architect an application is to feel the pain of doing it wrong beforehand.

I would say yes, it could easily be structured towards smaller applications. There is a learning curve towards getting started, but honestly, it helped me understand WPF better than attempting to start from scratch. After starting a project with CompositeWPF and then starting another project without it, I found myself attempting to duplicate features of CompositeWPF on my own because I missed those features! :)