Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Since I'm new to Xamarin forms, I'm not quite aware of How to arrange your Xamarin form project in a good folder structure?
For eg. I have a project which contains following files :
Network calling
Database handling
Views creations
Model-View bindings
Utilities etc.
NOTE: Xamarin Form itself has Xamarin.iOS and Xamarin.Android solution folders and the above mentioned files could be common to both Android and iOS.
Typical Application Layers
Data Layer – Non-volatile data persistence, likely to be a SQLite database but could be implemented with XML files or any other suitable mechanism.
Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without exposing implementation details to the caller. For example, the DAL may contain SQL statements to query or update the data but the referencing code would not need to know this.
Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic. Candidate for Business Façade pattern.
Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and images from remote servers. Encapsulates the networking behavior and provides a simple API to be consumed by the Application and UI layers.
Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the application (not generally reusable). A good test of whether to place code in the Application Layer versus the UI Layer is (a) to determine whether the class has any actual display controls or (b) whether it could be shared between multiple screens or devices (eg. iPhone and iPad).
User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.
Each of these layers represents an individual Solution Folder.
And each Layer should also be a different ClassLibrary(Portable)(see Encapsulation)
Also worth reading in this documentation:
Encapsulation, Separation of Responsibilities, Polymorphism
Taken from Xamarin Developer Guide - Achitecture
I also found some more info here.
There isn't a full agreement on which option is better - using Shared projects or Portable Class Libraries, but those are options for code sharing.
Personally I agree with Miguel de Icaza, Xamarin lead that if you don't share your code across other apps Shared projects are better, but as he said some people in Xamarin think opposite.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
At my job we use Entity Framework for data access. I am creating a Data Access Layer, a Business Access Layer and a few different types of projects to access the BLL (webAPI for client applications to interface with, multiple MVC websites and a few different desktop WinForm applications).
I added the DTOs to a separate project named "DTO". The goal of this project within this solution is to have a DLL with all the definitions for the classes and interfaces that will be past back and forth. That way this one project can be created as a git submodule within other solutions and updated for all the UI projects to use collectively. I will not be working on all the UIs as we bring more developers into the project and we will probably need to have multiple VS solutions.
My thought was to have the Data Access Layer pass back and take in DTOs instead of entity objects. This would decouple the process completely.
If we ever wanted to replace the DAL with something else as long it followed the interfaces defined in the DTO project we should be fine. I also think it would make testing easier as I can replace the DAL with a project to generate the DTOs with something like Seed.net. BTW replacement is a real possibility given our environment.
Is adding this layer of complexity bad or against design standards? Is there something I am missing?
This is the way I work, and having worked in the Cloud world for some years now, it seems to be the way everyone works.
Typically you have the following Projects (each build to an individual Assembly)
- REST controllers
- Models
that are used to pass information between Controller layer and Business Logic
- Business Logic Interfaces (like ImyService)
- Business Logic (like myService)
- DTOs
- IRepository (like ImyRepo)
- Repository (like myRepo)
--> this is the same as DAL.
The great thing with doing this is that if you add Dependency Inversion (IoC) then you can make a mock Repo, in order to isolate and test the Service (Business Logic) layer and so on by injecting it into NUnit unit tests.
Quite often people in the industry (including me) use AutoMapper to convert Models to DTOs to Entities and the reverse.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm writing a web api app that I have divided into various projects such Web, Services, DataAccess - so basically the web api controller contacts the service layers which then can access the data access layer.
I was returning just a bool to let me know if the data access method has completed ok, then picking this up in the service layer and then back to the controller...where I can then respond with a HTTPStatusCode of 200, or 500 etc..depending whether or not the operation has returned a true or false.
Instead of bool is it good practice to use HttpStatusCodes instead...or should HTTP status codes only be used in the Controller - to return a response to the app that's calling the web api or should it be something else?
Thanks,
First of all classes should have the least possible knowledge of the world around them. Suppose you implement the repository pattern to fetch data. Your repository (data access layer) should not even know about HTTP, nor it should expect to be a part of web application. Its only concern is accessing a particular table.
It’s difficult to suggest specific solution without understanding the big picture, but you may consider the following:
Raise an exception if your application depends on data that couldn’t be fetched. It’ll propagate as 500 response.
Use enum instead of bool to make code more readable.
Create DataResponse class to incapsulate result of data access operation. You may then use the adapter pattern to adapt DataResponse to HttpResponse.
Vague question, but I'll attempt an answer.
This really depends on the reason for separation between the layers, and what each layer is concerned with. One question I would ask myself is why do you have a Service layer? Is it because it contains the business logic? Is it because intent is to have an option to reuse it outside WebAPI context? Or do you expect Service layer to have dependency on WebAPI context (i.e. that it is a web request, and not service being reused say inside a winform.)
Most likely, you want to constrain dealing with HTTP particulars to the Controller (IMHO, this is obviously just my opinion). But I'd refrain from using it as a hard and fast rule.
You shouldn't be propagating http status codes down or up the line. If you do then you are injecting dependency on what you worked so hard to decouple. One of the great things about N-tier architecture is that yeah, your web layer may be primarily used for interacting with your service layer but what happens when you want to hook up a native mobile application to call it, or a windows service to call it, or a desktop app to call it. You are basically handicapping its potential by trying to persist that error up and down the chain.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We currently have a single database with users, customers, products and orders logically separated by schemas. We then have several MVC.net applications accessing the database via their own BLLs. Each of these applications have their own functionality and share some aspects with some/all of the other applications.
Currently, some code is duplicated in these BLLs and it's a bit of a mess to maintain. It does however, allow us to develop features quickly and deploy each application independently (assuming on major database work here).
We have started to develop a single access layer, properly separated out that sits above the database and is used by all of our MVC.net applications. Logically this makes sense as we can now share code between our applications. For example, application A can retrieve a customer record in the same way as application B. The issue comes when we want to deploy an application, we wouldn't be able to deploy one application, we'd need to deploy them all.
What other architectural approaches could we consider that would allow us to share code between our applications and deploy those applications independently?
A common solution is to factor out services (based on an arbitrary communication layer REST, WCF, Message Bus, your choice with versioning) and deploy these services to your infrastructure as standalone services.
Now you can evolve, scale and deploy your services independently of the consumers. Instead of deploying all applications you now only have to deploy the changed services (side-by-side with the old ones) and the new application.
This adds quite a lot of complexity around service versioning, configuration management, integration testing, a little communication overhead etc. So you have to balance the pros and cons. There are quite a bunch of articles on the net how to build such an architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
My MVC's controller actions are getting huge. I want to create a service layer so that I can move code there. The idea is to use the SOLID principle: the controllers use the service layer to get the domain models that will be then transformed into view models.
My question is simple: Should my service layer be a new assembly (project) that will go along with my MVC project or should it be simply a class inside my already existing assembly (MVC Project)?
My approach will be similar to the following one, but unfortunately the post doesn't explain exactly how was the service layer defined:
http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
I would consider making the service layer a separate thing.
Service can be an interface-based object that is implemented either in-memory in the application or distributed and accessed remotely via SOAP, REST, RCP-XML, or anything else. The controller/client need not know or care if they have a client program that's interface based as well.
A dependency injection, interface based solution would allow you to inject client and service implementations in pairs so controllers need not be disturbed if you change how to access the services.
Controller is usually closely tied to a view. Views come and go, but services tend to remain. Services should map to business functionality that could be shared across applications.
Should my service layer be a new assembly (project)
Yes, it should. Other UIs might want to use it in the future...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been developing web apps using .net and c# from last 1 year, but there is some confusion going on in my mind regarding OOP principals implementation.
1) What i learned from the object oriented books was that every class should have its specific methods, but when i came across the code of a senior developer, i saw that the developer has created a separate business layer with a business layer class containing all the methods of all the classes.
Is this approach of using separate business class containing all the methods being used in our app is justified by any design pattern or by any other resource, or it is just an awful design?
Please elaborate your answer in detail as this can also helps other newbies out there...
Architecture is an art not a science. There are good architectures and bad architectures, but there is not a single correct architecture.
For example your Senior developer may have created a Facade (design pattern) on top of your more complicated data access layer to simplify data access. For instance you could have a dozen entities for ordering a product, and you would like to create a facade for everything you need to do while ordering a product.
Just look at the architecture and try to analyze yourself if you think it could be better. The more architecture you know the better your judgment will be, but architecture is rarely black and white.
Also, just because someone is senior it doesn't necessarily mean that they know what they are doing or that they don't make mistakes.
Also, Inheritance can be done in EF:
Inheritance in EF
there is no single architecture one can follow, for example when building strictly SOA systems it is VERY common to have model classes that are only data, no methods whatsoever. Whereas all the business logic classes exist in a different namespace. Furthermore when you send your domain classes over the wire you will typically create dedicated classes for that purpose in a different assembly dedicated to the SOA.
The architecture I describe above is directly from the Microsoft Architecture Guidance package for VS.