Description:
I have a solution in Visual Studio which has multiple projects as application layers.
Business Logic (.NET Standard)
Data Access Layer for database operations (.NET Standard)
Web Application (.NET Core)
Xamarin Forms Mobile
Xamarin Android
Xamarin IOS
Xamarin UWP
Question:
In which layer should i create my MVC controllers as a good design practice for this scenario?
Controllers belong in the web layer as they handle web related activities such as routing, handling incoming http requests, etc.
Ask yourself what a controller is meant to do and then see which layer those activities make sense in... does handling incoming http requests make the most sense in a data layer? no, the data layer should be related to data I/O.
Does handling incoming http requests make the most sense in a business logic layer? no, the business logic should contain logic only needed to do the business/domain logic of what you're building.
Does handling incoming http requests make the most sense in a web layer? Well yes, http requests are part of the web as we know it.
There is an awful lot of information about n tier (aka onion) architecture on the web. Here is one example I quickly dug up that goes into more detail than my answer above
Related
I'm working on an .Net application in which a user can either use a Xamarin Android app or a web application to use the system. I would like to put all the business logic at one place and both the applications shall use it.
Considering that I have "NO" experience in Web APIs or Services, how shall I design my application?
However, I'm ready to learn both (Web APIs or Services) if required for the implementation.
Considering that I have "NO" experience in Web APIs or Services, how
shall I design my application?
The question should rather be, do you need to call some external services, or can you do everything locally on the phones? If some external services are required, you need web API call from your different platforms. The business logic goes in your API.
If everything can be done locally, you can just share your client side code.
As you probably know, Xamarin app's usually follow a MVVM architecture.
It does not mean the business logic must be in the sharing ViewModels (I actually wrote a blog post about that if it you want more information).
The business logic must be in the domain models, and possibly some services.
Thus, in the end you can share the c# code of your domain models and business services between your xamarin app and your web application.
Hope it helps.
I'm writing simple CRUD-like MVC app at the moment, trying to learn proper N-tier architecture, and so far i had MVC which gets objects through WCF which call my Data Access layer to get those objects from Database.
However I just realized most likely huge mistake I'm making, I left all generated authentication stuff where it was - in MVC project except ApplicationUser and ApplicationDbContext which i moved to Business layer and Data Access layer accordingly and referenced them which I think defeats purpose of Service. How do I move properly authentication to service in this case? Perhaps there is a sample N-Tier project which has authentication moved to service and all?
So far my references are like this:
MVC client knows about Service(as service reference), Business layer
Service knows about Data Access, Business Layer
Data Access knows about Business layer.
this might help you! this explains asp.net identity with Design Patterns
http://timschreiber.com/2015/01/14/persistence-ignorant-asp-net-identity-with-patterns-part-1/
I have MVC application in which the controller sends out emails based on trigger actions on the view. This works correctly. The project also has a business layer dll which is use to interact with the SQL server database. This works correctly. It is now come to my attention that a website under construction needs to access the controller dll to send emails. Right now the website only works with the BLL. With the data objects being different between the website an the application, how do utilize the same code so that both projects can send emails? I am using Razor templates to create the emails, if that makes a difference.
Upgrade to at least MVC 4 and start utilizing the Web API capability to offer a web service to the other application in development.
Here is a good starting blog post
We have the following structure on our project in order to get data.
Acces to Database Using Entity Framework
ProjectName.DAL
Services that call Entity Framework.(UoW)
ProjectName.Service
Our Actions inside Controllers call Services and return data needed.
ProjectName.Web
The Question:
Our services take info directly with Entity Framework, What are the advantages and disadvantages about creating WebServices in order to replace the connection with EF? "In that case only WebServices will have access to Entity Framework,"
ProjectName.DAL
ProjectName.WebServices
ProjectName.Service
ProjectName.Web
The main advantage is that you would have a more decoupled design.
By exposing your DAL through web services you "disconnect" it from your frontend. For example, a mobile app, a web app and a WPF desktop app could all access your DAL through the same web services. So you can reuse your DAL accross different apps which can save you a lot of development time. Have a look at ServiceStack and advantages of its web services.
Disadvantages? Having to do some additional development work and testing. If your app is a simple and will not be used in different environments it may be overkill to use web services.
Disadvantages:
Web services tend to consume more resources from your server than just a plain CLR (aka dll) layer in your project.
whatever web service you plan to use (legacy web services, service stack, wcf, Web API, etc) you'll find that all of them have to use a process to serialize the data and it could be the case that you'll need to do the inverse process in your front end application.
you have to design your ws very carefully because you have to think how you're going to expose those services and the level of encapsulation/abstraction you will have to put in place, a bad design in a web service layer definetely will be a headache for you during development and production.
Security: In most cases you will have to validate every input in those web services as well
Advantages
well that's very relative to call an advantage, it depends more on what are your app requirements, some questions you need to answer are like the following:
Do I need to share data with other apps (mobile, desktop, other web
apps)?
Do I need to expose some functionalities to other business (third
parties)?
Recomendation
If you plan to do a CRUD application I'll recomend to go with REST definetely is the best option due to it's architecture (POST,DELETE,GET,ETC).
if you don't need you a web service right now, you can try to develop your service layer kind of like a service implementation in service stack but try to remain as POCO as possible and if for some reason you'll need a web service you can try to refector the service layer intead to have another level of indirection in the middle.
just my two cents...
I'm just starting a project where I would like to use Kendo UI (based on jquery) with C#. A few weeks ago I was successful in handling requests using Web Services (asmx), was pleased with the results and performance, and was able to create forms quickly.
Since this is a new project, I thought I could look into different concepts such as MVC and WebApi. I found MVC to be the most complicaded so I went for WebApi and started playing with controllers and requests. So far what I'm finding (don't judge me, I'm new to these new concepts), is that Web Service seems to be simpler and more flexible.
So I guess what I'm looking for is... what are the main advantages of using MVC vs WebApi and even vs Web Services. Are there any downsides to Web Services? Would it be a bad practice to have my data layer controlled by Entity Framework, all models defined, and my requests handled by Web Services?
Any clarifications are welcome. Thank you.
In a broader sense, Web API is used to create Web Services ! It uses HTTP as its standard for creating services (instead of SOAP like in asmx) as its more open and any type of client like a mobile app, desktop app, web app etc will understand HTTP protocol. Another advantage is that u can easily use JavaScript/jQuery to communicate with your Web API. With SOAP web services, its a nightmare!
Kendo UI and Web API is a great combination. We have recently created a mobile iPad app using this combination and it worked like a charm. We also used Entity Framework with oracle as back end DB and it never gave any issues.
Webservices are nice if you have the need for it. A need as in needing that logic/data in more than one different type of application (such as web, and a mobile app, and a desktop app). (Or if you want to sell the service you're providing)
Using a webservice for ONLY a website which you don't except to expand to other things is complete overkill.
Furthermore, the MVC framework and the Web Api framework are pretty similar except web api is used exclusively for webservices. Coding in both of them will be the difference between white bread and wheat bread.