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.
Related
Brief overview, I am working with Visual Studio 2017 and .Net Core 2.1. I am about to begin development on a website which will handle integrating 3 existing pieces of software which our company uses.
I have created WCF services already for use by some of the applications I have developed, but for this project, there are multiple APIs which I will be utilizing. It's quite possible that I may need to use these APIs in other projects down the road.
I apologize if this is an opinionated question, but here it goes, do you think it is good design to develop one central API which wraps all the calls to the integrated system APIs? My thoughts were that in this way, I only have to write the code once for making the desired API calls and I can then add to this API as I see fit moving forward, ie. another system API is needed.
Please feel free to give advice, I am still learning and appreciate constructive advice. I am using this to get started on building my API using .Net Core 2.1, https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-2.1
If the APIs are related then yes it does make sense to create a single assembly to call those for you and deal with the responses. You'd then consume that assembly in all your other apps.
However, if the APIs are completely different and require different set ups, then it may make more sense to create an assembly wrapper for each to keep the concerns separate.
You don't want to confuse the APIs. If anyone was to look at your code or assembly, they should be able to say that it relates to what it describes and not have to guess.
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.
I am trying to develop a .NET 3.5 service application that uses:
WCF for the service layer
Business object layer to encapsulate our business logic (and isolate the service and data access layers)
Linq-to-SQL for the data access technology
Unity for dependency injection
Enterprise Library 5 with the following:
Validation Application Block
Exception Handling Application Block
Logging Application Block
We are also looking to follow TDD and want persistence ignorance (PI) as we may be changing data access technologies to either NHibernate or EF when we upgrade to .NET 4.0 later in the year and we want to minimize the impact such a change will have by isolating it to just the data access layer.
I have been working with the application for a little over a week now and have quite a bit of it working. I have yet to get the EHAB or LAB implemented successfully, validation is only partly implemented and PI is non-POCO based because we are required to support the designer (as opposed to using XML mapping). We are using the repository pattern with interfaces for PI.
Can anyone point me to some quality (real-world) example solutions using these technologies together? That's probably the best way to address my questions and concerns because the articles I've referenced thus far only touch on one or two aspects of my solution and things aren't working exactly the same as they describe when I wire all of this together.
Have you tried looking through p&p hands-on labs:
download sample solutions and instructions
These are pretty easy to work through, giving you guidance and usage patterns.
I'm maintaining an application which currently is just a web service (built with WCF) and a database backend. The web service is built in layers with a linq-to-sql data access part with core functionality in an own assembly and on top of that the web service assembly which contains the WCF code. The core assembly also handles all business logic rules (very few actually).
The customer now wants a Web interface for the application instead of just accessing it through other applications which are consuming the web service. I'm quite lost on modern web application design, so I would like some advice on what architecture and frameworks to use for the web application. The web application will be using the same core assembly with business rules and the linq-to-sql data access layer as the web service.
Some concepts I've thought about are:
ASP.NET MVC (or MVC-2)
Webforms
AJAX controls - possibly leting the AJAX controls access the existing web service through JSON.
Are there any more concepts I should look into? Which one is the best for a fresh project?
The development tools are Visual Studio 2008 Team Edition for Developers targeting .NET 3.5. An upgrade to Visual Studio 2010 Premium (or maybe even Ultimate) is possible if it gives any benefits.
Definitely dig into ASP.NET MVC2.
All of our projects are now being developed using ASP.NET MVC2. It's not just highly scalable. It's highly testable as well. Which leads to way better maintainable apps in the long term.
WebForms vs. MVC2 points - (speaking out of experience):
Scalability:
In our company we had a lot of applications using WebForms which then were updated and changed by us as needed by our customers.
I think your customer will be requesting more changes on the application in near future. Making calls to other services, and maybe you'll have to rework parts of the final product to match their wishes.
And with the upcoming Cloud Computing and the Windows Azure platform you'll probably need to keep up with your code.
ASP.NET MVC absolutely supports the concept of being able to scale up your application any time you want.
I remember one of our customers walking up on me asking me for an extension for their app (they have a member management system) and the feature would contain something like a link to export the current view as a csv file so they could do office stuff with it (mostly serial letters).
It wasn't really a big problem setting that feature up. (took around 2 hours including writing tests) - let's go to tests:
Testability:
Using WebForms we didn't really have much interest writing tests because it was a pure pain to do so.
I remember writing some tests to have at least some proofs but let's drop that topic.. (:p)
We had tests for our custom classes but we couldn't really test all the EventHandlers within the WebForms.
Our CodeBase is way cleaner and saver to use thanks to this testable environment. I just check out some of the code, modify it, run all the tests and: Oh, it broke on strange behavior! - Let's fix that again. Earlier, I remember sitting with my co-worker debugging and trying to find those bugs for hours.
With ASP.NET MVC2 we are now lacking tests!
We ask all kinds of people (even the non-Web ones) to provide test-cases we could feed into our TestSuite.
And yeah, there are some AJAX-Controls too:
AJAXability:
You asked about AJAX Controls and in conjunction with ASP.NET MVC I highly recommend you to check out Telerik ASP.NET MVC UI Controls.
If that isn't something for you, we also make extensive use of jQuery and jQuery UI
With ASP.NET MVC and the HTML Views, those libraries aren't just a pleasure to use, they just look amazingly beautiful.
There is no random-html-tag-id-value autogeneration anymore!
But what I like most is: You can finally really re-use your code again.
There is so much more to those frameworks than just that, there is the T4 templating system. Auto-Scaffolding for your ViewModels / DomainModels with the Html.EditorFor() method and of course there is a great and easy way to use the IoC and DI paradigms.
Assuming that you have asked the question with mostly .NET Framework related tags, you'll probably stick with it.
Just to keep the post complete, there are also other frameworks that are just as good (or even better):
Ruby on Rails
Django
CakePHP
And many many more!
There's also DynamicData which may be appropriate if you need simple CRUD access to your data.
The Web Service Software Factory (WSSF) might come in handy in your situation.
This will allow you to define your contracts (XML entity returned (if XML you choose), etc.) while designing the server/client communication using WCF (or standard Web Service communication protocol).
WSSF favors either ASP.NET MVC or ASP.NET MVP. A simple example of the MVP architecture is shown here, plus this article.
As for me, I often come with a hybrid-like architecture using a bit of both MVC and MVP, as both have different strong points which combined together fill each other's improvement points.
I'd also recommend looking into Silverlight.
http://www.silverlight.net/learn/
Just my opinion to use MVC on Client sites and WebForms inside administration pages(site)
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! :)