Data Transfer Object, Business Object, Domain Object or something else? - asp.net

In database I have table: Notes and table Comments. In my solution I have 3 projects: DAL, BLL and Web.
I need to show a user notes with comments which aren't set as spam so I have created in DAL project that class:
public class NotesWithComments
{
public Notes Note { get; set; }
public IEnumerable<Comments> Comments { get; set; }
}
I use above class in each project: DAL, BLL and Web. Is this class Data Transfer Object, Business Object, Domain Object or what?
In a repository class I have that query:
public class NotesRepository
{
DatabaseContext context;
public NotesRepository(DatabaseContext context)
{
this.context = context;
}
public IQueryable<NotesWithComments> GetNotesWithNoSpamComments()
{
IQueryable<NotesWithComments> notesWithNoSpamComments = context.Notes.Include(x => x.Comments).OrderByDescending(x => x.CreateDate)
.Select(x => new NotesWithComments
{
Note = x,
Comments = x.Comments.Where(y => y.IsSpam == false).OrderBy(y => y.CreateDate)
});
return notesWithNoSpamComments;
}
}
In BLL project I use the method from the repository class:
public class NotesService
{
private readonly IUnitOfWork _unitOfWork;
public NotesService(IUnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
public IEnumerable<NotesWithComments> GetNotesWithComments()
{
IQueryable<NotesWithComments> result = _unitOfWork.NotesRepository.GetNotesWithNoSpamComments();
return result;
}
}
And in Web project I use the method form the service class:
public ActionResult Index()
{
List<NotesWithComments> result = _notesService.GetNotesWithComments();
return View(result);
}

Since it neither exposes any behavior (properties or getters/setters don't qualify) nor encapsulates its structure (again, properties or getters/setters that do nothing but expose the underlying data don't qualify) it is no object at all.
No matter if the language you use calls it an object or not. It is just a data structure (which is perfectly fine if you only want to move data from one place, like a database, to another, like a UI.)
Or, to quote Dan North:
Data Transfer Object is an oxymoron

Is this class Data Transfer Object, Business Object, Domain Object or
what?
A DTO is typically a class that is mainly used for transferring data between layers or some type of boundaries..typically just an object with no behavior.
I have always referred to Domain Objects as something that maps directly to a database table. So In your example, your domain models would be Notes, and Comments.
I would consider your NotesWithComments object a dto, or possibly a view model (as you're using it as your asp.net mvc model for the view).
The practice I would normally use here is use your NotesWithComments as a dto (transfer data, no behavior, easily serializable, very clean ect), and create another class to act as your view model.
In the beginning these classes would probably be very similar, possibly the same..but if you make changes over time, or your view needs to display different things, you would just change your view model, and populate it from other dtos, or tranform your data however you need to. You could also then get rid of the properties on your view model that your view doesn't need.. (unless your view magically maps directly to every property on your current dto). It's a bit more work up front but if you're working on a big long living project I think you'd be happy you did it later on.
So you would populate your domain models using EF in your data layer, you would then use your dto and transfer that data to the Biz layer, do w/e you need there, then use your dto (could be the same one) to transfer your data to your presentation layer (mvc), and populate your view model from the dtos you receive.
Anyway that's my take on it.

Related

ASP.NET MVC to Existing ASP.NET App with BusinessLayer.Better way to load ViewModel objects from Existing BusinessLayer?

I have a legacy asp.net web application which has 2 layers , UI and BusinessLayer. The UI project is of type ASP.NET website and BL is of type class library. The BL project has classes for entities of my app like Customer,User,Empoloyee etc.. Each class has methods for Reading from Database and Populate the object properties from the DataReader.that means the Customer Class contains my Customer object and Data Access Methods together.
Now I changed the web app to support MVC too. The old site (webforms) works as it used to be and the new upgrade to the site i am making (adding admin features to manage the site) is in ASP.NET MVC3. The routing and everything works fine. But i am worried about the structure /maintainability of the project.
For the new MVC part, I had to create ViewModels for few of the Entities like CustomerViewModel,EmployeeViewModel. I created another class called "CustomerService" With methods like GetCustomerViewModel and inside that method i call the GetCustomerMethod from the Existing BusinessLayer and read property values from the object ( of entity type mentioned in the existing BL project) and assign that to the CustomerViewModel (I will look into some AutoMapper samples for this later)object and return that from this method. My View will use this object to show data in the UI. The reason i created the "CustomerService" class is i may need to do some if condition checking or some business validations before setting the values to CustomerViewModel object. I consider that as a "Middle Layer / Service layer" so that my Controllers will be thin.
From my Customer Controller
public ActionResult Details(int id)
{
MyProject.MVCViewModel.CustomerViewModel objCustomerVM;
objCustomerVM=MyProject.MVCMiddleLayer.CustomerService.GetCustomerViewModel(id);
return View(objCustomerVM);
}
In my CustomerViewModel
public static CustomerViewModel GetCustomerViewModel(int customerId)
{
//Create an object of new ViewModel
CustomerViewModel objCustomerViewModel = new CustomerViewModel ();
//Get an object from Existing BL of Customer of type ExistingBL.Customer
ExistingBL.Customer objCustOld=new Customer(customerId);
//Check some properties of the customer object and set values to the new ViewModel object
if(objCustOld.Type=="normal")
{
objCustomerViewModel.Priority=2;
}
else if(objCustOld.Type=="abnormal")
{
objCustomerViewModel.Priority=1;
objCustomerViewModel.Message ="We love you";
}
//Some other checking like this....
return objCustomerViewModel;
}
Is this a wrong approach ? Is my code going to be messy ? I am not happy about the ViewModel since it is (almost) the duplicate code from my Existing BL entities. What is the best way to address this scenario. I am not sure about using Repository Pattern (which i saw in most of the examples) in this case ? Should i do that ?How is it going to improve my code ?
The approach that I would take would be similar to repository pattern. I would outline few key points
Since the only thing that you would be rewriting would be UI logic (View Model Object), and its fine as your UI technologies are different(asp.net vs MVC)
I would suggest you start working on interfaces so that later on you could do a dependency injection. The biggest benefit I generally with dependecy injection in mvc is while writing NUnit test cases.
public static ICustomerViewModel GetCustomerViewModel(int customerId)
{
//use DI, rather than concerete implementation
ICustomerViewModel objCustomerViewModel = new CustomerViewModel ();
//use DI, rather than concerete implementation
ExistingBL.ICustomer objCustOld=new Customer(customerId);
.
.
.
return objCustomerViewModel;
}
You could now very easily create mock objects with the help of any mocking frame work.
More or less my ViewModel classes are a redefinition of properties with only attributes, someone may argue that this is just another overhead layer, but I do this for a simple reason: I can add proper Web Validation's attributes without breaking anything (The DataLayer shoudl be shareable with other apps).
In shorts given a DataLayer class exposing a User object:
public class DalUser {
public int Id { get; set;}
public int Age { get; set;}
public string Name { get; set;}
public string Surname { get; set;}
// Business method for reading/writing/deleting
}
My viewmodel is something like:
public class VmUser : DalUser
{
[Display(Name="ID Code")]
public override int Id { get; set; }
[Display(Name="Age")]
[Required]
public override int Age { get; set; }
}
This leads me to two goals: the former is I can use Attributes without worrying about breaking something else, the latter is I can hide from user some field, prevent field injection (e.g. from FireBug - but that's includes defining an Interface and using that, not plain subclassing).
That's proves pretty usefull within my corporate (we're doomed to use EntitySpaces) and it's one of the less ugly way I've found in order to partially reuse ES generated classes.

ASP.NET Site, EF, Layered Architecture, is my design ok or should I correct it?

I have a DAL project, with an entity data model context bound with EF 4.1
I provide methods to access this context through a "Business" project.
My question is the following:
I'm thinking I shouldn't reference the DAL project from somewhere other than the Business project, so my thinking is, I could add "DataContract" interfaces to the Common project I already have, reference this project within the DAL project, extend the partial classes EF has autogenerated for me, inherit the DataContracts corresponding to each of them, and use these DataContracts as the return value of operations in the Business project, thus isolating the DAL project and avoiding to tightly couple it to either the business, or web projects
Is my thinking correct or am I way off?
Update In re-reading my own question I find this kind of hard to follow, here's an example of how I'd do it, with one of the entities in the model:
The entity is:
namespace Application.Website.Main.Common.DataContracts
{
public interface IServerApplication
{
string Id { get; set; }
string ApplicationName { get; set; }
byte MaxAccountsPerUser { get; set; }
bool Enabled { get; set; }
}
}
This would be in the Application.Website.Main.Common project.
In the DAL project, I would reference the Common project, and extend the partial class of the ServerApplication to inherit from that interface, no further changes required.
namespace Application.Website.Main.DAL
{
public partial class ServerApplication : IServerApplication
{
}
}
In the Business project, I would reference both the DAL and the Common projects, and I'd use these DataContracts as return types:
namespace Application.Website.Main.Business.Entities
{
public class ServerApplication
{
public static IEnumerable<IServerApplication> Enabled()
{
var context = HttpContext.Current.GetDataContext();
return context.ServerApplications.Where(a => a.Enabled);
}
}
}
For completeness, this is the GetDataContext() extension method, placed in the DAL project:
public static class HttpContextExtensions
{
internal const string _contextDataKey = "dataContext";
public static EntityDataModelContext GetDataContext(this HttpContext httpContext)
{
if (httpContext.Items[_contextDataKey] == null)
httpContext.Items.Add(_contextDataKey, new EntityDataModelContext());
return (EntityDataModelContext)httpContext.Items[_contextDataKey];
}
}
By the way, where should I be doing the try/catching?
Should that be done on each of the Business-level methods that use the data context?
Or somewhere else?
What would be the best way to handle exceptions at this level?
Update I found a hole in my logic. If I wanted for instance to have a method in the Business class for a given entity, it would either have to be static and/or an extension method to the interface. Like this:
namespace Application.Website.Main.Business.Entities
{
public class MembershipUser
{
public static int GetRequestCount(this IMembershipUser user)
{
var context = HttpContext.Current.GetDataContext();
return context.ServerAccountRequests.Count(r => r.MembershipUserId == user.UserId);
}
}
}
Or, alternatively, just passing the least information I require for the query:
namespace Application.Website.Main.Business.Entities
{
public class MembershipUser
{
public static int GetRequestCount(Guid userId)
{
var context = HttpContext.Current.GetDataContext();
return context.ServerAccountRequests.Count(r => r.MembershipUserId == userId);
}
}
}
But how could I make a class so I can just use instance methods, like user.GetRequestCount()? Then the DataContract would need to be a class and not an interface... Or maybe I should have this class to also inherit from the DataContract, but then I would have to implement all of it's members, which I don't intend to do again, since that's already handled by EF at DAL level
I'm thinking I shouldn't reference the DAL project from somewhere
other than the Business project...
Depends how you reference it. The short answer is even you Business Logic (BL) shouldn't reference the DAL's physical implementation, it should reference an interface that defines the DAL; the concrete impelentation should then be loaded dynamically.
This is on the assumption that the project is beyond trivial in size - you can still write small PoC's, etc, anyway you like.
I could add "DataContract" interfaces to the Common project I already
have
I'd define the data contracts in their own assembly and not in a common project, otherwise everything that references the common "knows" about the data contracts (is that really what you want), and if you have any dependencies in the data contract then everything that references the common will get those extra unwanted dependencies as well.
Although I defining the data contracts should be it a separate assembly, the DTO/POCO objects could be in the common; I've done that before and had good results, because I use these objects to throw data between different layers - not just between the DAL and BL.
Your amin should be to keep all data access & EF references (like SQL) in the concrete DAL implementation.

How to allow client pass my object through webservice?

Sorry if this is stupid question, because I'm a bit confused about .NET remoting and distributed object.
I want to write a webservice, and in one of its methods, I want user to pass one my object's instance as parameter. It will greatly reduces number of parameters, and help user call this method more effectively. I create some class, but when distributing them to client, only class name remains, all properties and methods are gone, just like this
public class CameraPackages
{
private readonly List<CameraPackage> _packages;
public CameraPackages()
{
_packages = new List<CameraPackage>();
}
public void AddNewCamera(CameraPackage package)
{
_packages.Add(package);
}
public void RemoveCamera(CameraPackage package)
{
if(_packages.Contains(package))
_packages.Remove(package);
else
throw new ArgumentException();
}
}
into this: (in Reference.cs)
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.Xml", "2.0.50727.3082")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://tempuri.org/")]
public partial class CameraPackages {
}
How can I do to allow user use my object?
Thank you so much.
Web Services will only serialise public properties, so you can't do that (in that way) using web services.
You will need to manage your list of objects client side, then send the data in a transfer object (a class with just properties).
Have a look at this.

ASP.NET MVC design

As I've stated before I'm working on a digg clone to teach myself ASP.NET MVC Inside and out but I've hit a road bump that I can't seem to avoid.
I want to be able to optimize this application as much as possible so I have my DAL which is a bunch of classes of ...Repository : Repository. Now to help optimize for performance I have my base repository classes return my ViewData objects so that they can select extra fields needed without having to create an anonymous type.
Stories have Users who have created them and Users have Votes for Stories. Pretty easy DB layout. Now I handle my own membership because the default ASP.NET membership is so bloated. In my view for the list of stories I have to determine if the current user has voted on the story being rendered. Now since I figured data access in the View shouldn't be happening it should be in either my controller or my DAL. Since I'm already returning ViewData from my DAL i added another property on the StoryViewData type named "UserVotedOn" that returns true if the user has voted on that story.
Problem with this is I have to either A) make the DAL aware of membership or B) pass in the User ID into the query methods on the DAL. Neither of these feel right to me and I'm looking for some good solutions. Any feedback is welcome.
In my MVC apps I'm using architecture that Rob Conery showed on his MVC Storefront video series and it works like charm for me.
Repository => Service + Filters => Controller => View
I've tried to simulate what you want to achieve and managed todo like this
Edit1: Changed IList to IQueryable in repository and filters
Repository
public interface IRepository
{
IQueryable<Vote> GetVotes();
IQueryable<Story> GetStories();
}
Service for getting what you want
public class Service : IService
{
private IRepository _repository;
public Service(IRepository repository)
{
_repository = repository;
if (_repository == null) throw new InvalidOperationException("Repository cannot be null");
}
public IList<Vote> GetUserVotes(int userID)
{
return _repository.GetVotes().WithUserID(userID).ToList();
}
public IList<Story> GetNotVotedStories(IList<Vote> votes)
{
return _repository.GetStories().WithoutVotes(votes).ToList();
}
}
Filters to filter your stories and user votes (These are basically extension methods). Not the nicest implementation out there, but you can rewrite later
public static class Filters
{
public static IQueryable<Vote> WithUserID(this IQueryable <Vote> qry, int userID)
{
return from c in qry
where c.UserID == userID
select c;
}
public static IQueryable<Story> WithoutVotes(this IQueryable <Story> qry, IList <Vote> votes)
{
return from c in qry
where votes.Where(x => x.StoryID == c.StoryID).ToList().Count > 0
select c;
}
}
And then you can pass current UserID in controller, not in DAL or View like you had to do before
public class HomeController : Controller
{
private readonly IRepository _repository;
private readonly IService _service;
public HomeController()
{
_repository = new Repository();
_service = new Service.Service(_repository);
}
public ActionResult Index()
{
var userVotes = _service.GetUserVotes(CurrentUserID);
var unvotedStories = _service.GetNotVotedStories(userVotes);
return View(unvotedStories);
}
}
This allows you to stay away from adding user related UserVotedOn property to your Story model
It looks like you're missing the BLL.
Actually, the right architecture of an MVC application is what many people still trying to figure out.
I personally consider UserID to be somewhat a translayer concept. It will appear on both DAL and BLL levels.
Basically, your controller method should have just a few very basic calls to the BLL, only to determine how to react to user input, whether to return on view or another.
Your view should only deal with model objects. A model should probably be filled by the business logic. You could call BL methods in a controller method in order to initialize you model object and then pass it to the view.
Controller should not communicate directly with the database. Neither should it probably deal with low level objects which comprise your domain objects and models.
P.S. i would try to avoid extensive use of ViewData. Strongly-typed model classes are a much better option. You can also group them in hierarchies to inherit some common properties. Just like your domain model classes could derive from a base class that has a UserID property defined.

What to return from the DAL to BLL

I currently have an application which consists of:
User Interface (web page)
BLL (Manager & Domain Objects)
DAL (DataAccess class for each of my Domain Objects).
I use the following in the UI to search for a domain object.
protect sub Button1_Click()
{
IBook book = BookManager.GetBook(txtID.Text);
}
Here is my BLL
public class BookManager
{
public static IBook GetBook(string bookId)
{
return BookDB.GetBook(bookId);
}
}
public class Book : IBook
{
private int? _id
private string _name;
private string _genre;
public string Name
{
get { return _name; }
private set
{
if (string.IsNullOrEmpty(value))
throw new Exception("Invalid Name");
_name = value;
}
}
public string Genre
{
get { return _serial; }
private set
{
if (string.IsNullOrEmpty(value))
throw new Exception("Invalid Genre");
_genre = value;
}
}
// Other IBook Implementations
}
And finally here is my DAL
public class BookDB
{
public static IBook GetBook(int id)
{
// Get Book from database using sproc (not allowed to use any ORM)
// ?? Create IBook Item?
// return IBook
}
How would one create a IBook Object and return it to the Manager?
I'm thinking of returning a DataTable from BookDB to BookManager and having it create the Book Object and return it, but that doesn't seem right.
Is there another way to do this?
Edit:
I decided to seperate each layer into a project and ran into a circular dependency problem in the DAL layer when trying to add a reference to the BLL.
I can't access the Book Class or Interface or anything in BLL from DAL.
Should i just use ado.net objects here and have my manager create the actual object from the ado.net object?
Here's how its layed out
BLL.Managers - BookManager
BLL.Interfaces IBook
BLL.Domain - Book
DAL - BookDB.
Thanks!
You could create dummy Book objects that contain only data. Get, set properties and member values. This book, has 1 property for each field in the database, but doesn't validate anything.
You fill the object from the db, then send it to the BLL.
When you want to save the object, you also send it to the BLL.
Your classes in the BLL could wrap aroud those objects, if that makes sense. This way, it is easy to just send it back to the DAL.
Dummy Book:
public class DummyBook:IBook
{
private nullable<int> _id;
private string _name;
private string _genre;
public string Id
{
get {return _id;}
set {_id = value;}
}
public string Name
{
get {return _name;}
set {_name = value;}
}
public string Genre
{
get {return _genre;}
set {_genre= value;}
}
}
DAL Book:
public class DALBook
{
public static IBook:GetBook(int id)
{
DataTable dt;
DummyBook db = new DummyBook();
// Code to get datatable from database
// ...
//
db.Id = (int)dt.Rows[0]["id"];
db.Name = (string)dt.Rows[0]["name"];
db.Genre = (string)dt.Rows[0]["genre"];
return db;
}
public static void SaveBook(IBook book)
{
// Code to save the book in the database
// you can use the properties from the dummy book
// to send parameters to your stored proc.
}
}
BLL Book:
public class Book : IBook
{
private DummyBook _book;
public Book(int id)
{
_book = DALBook.GetBook(id);
}
public string Name
{
get {return _book.Name;}
set
{
if (string.IsNullOrEmpty(value))
{
throw new Exception("Invalid Name");
}
_book.Name = value;
}
}
// Code for other Properties ...
public void Save()
{
// Add validation if required
DALBook.Save(_book);
}
}
Edit1: The dummy classes should go in their own project(Model, just as stated in the comments is fine). The references would work as follow:
The DAL References the Model Project.
The BLL References the Model and the DAL.
The UI References the BLL.
BookDB should return the IBook instance. I like the repository pattern, which is all about mapping from the db to the domain.
The repository implementation returns instances of the domain objects. This shields the rest of the code from the particular persistence implementation, which can be affected by the technology (database type, web service, [insert something else]) and the format used to save the data.
I would probably use ExecuteReader to create an object in code from the database. The reason for this is that the datatable has more overhead than a reader, because it has more functionality (and was probably created by a reader). Since you aren't doing updates/deletes using the datatable, you don't need the overhead.
That being said, I would make a static helper method in the BookManager class.
internal static IBook BookFromReader(IDataReader reader)
{
Book B = new Book();
B.Prop = reader.GetString(0);
B.Rinse = reader.Repeat();
return B;
}
The reason for this is because the reason you have an interface is because you might want to change the implementation. You may eventuallu have INovel : IBook, IReference : IBook etc and then you'll want to have an abstract factory implementation in your data layer.
public static IBook GetBook(int id)
{
// SqlCommand Command = new Command("SQL or sproc", ValidConnection);
using(IDataReader DR = Command.ExecuteReader(id))
{
// checking omitted
switch(DR.GetInt32(1))
{
case 0:
return BookManager.BookFromReader(DR);
case 1:
return BookManager.NovelFromReader(DR);
etc
}
}
}
Another benefit of the DAL here is that you can cache lookups. You can have a Dictionary that holds books you've looked up, to reduce extra db calls on objects you've already returned. When an update takes place, you remove the cached entity... That's another post though.
If you're using multiple assemblies, interfaces and helper methods will need to reside in a neutral (non-dependent) assembly. Right now in the blog-o-sphere, there is movement towards less assemblies, which means less dependencies, etc.
Here is a link from a blog I read on this topic:
http://codebetter.com/blogs/patricksmacchia/archive/2008/12/08/advices-on-partitioning-code-through-net-assemblies.aspx
Ultimately, I think the answer is that the data layer returns an instance of your interface to the business layer.
Good luck :-)
In my opinion you should never let DAL access BLL. That is an unnecessarily dependency.
Putting the Book class into a new project (perhaps named DomainModel) will fix the circular reference. You could do something like this:
Project BLL reference DAL and DomainModel
Project DAL reference DomainModel
Project UI reference BLL and DomainModel
Project DomainModel reference nothing
The DataTable you want to return is database related, and for BLL, it shouldn't care about what database you are using and what the schema is.
You may use a DB-Object Mapper to map the dbtable to an object in DAL.
If you don't want to return a DataTable, you can pass in an IBook implementation from BookManager for the DAL to populate.
To follow the intended model. the Data Access Layer (DAL) is responsible for retrieving and sending data from and to the data source.
The DAL must not care about any of the business entities your BLL is using as its only job is to retrieve data and return it in a neutral object. It must be neutral for generic reuability, otherwise you might as well not separate the layers as you are defiting its purpose.
Your Business Logic Layer (BLL) must not care how the DAL achieves retrieveing or writing data.
To communicate between the BLL and the DAL you must use neutral objects.
Your BLL passes an object's properties as individual paramters to the methods in the DAL.
the parameters in the DAL are neutral using strings, int, bool, any other .NET objects which are neither specific to a version of the database you are communicating with nor are specific types only existing in your BLL.
The DAL will retrieve the data from where ever by what ever means and return a neutral data object to the caller. This for example could be a DataSet or DataTable or any other object NOT specific to a database type/version your are using. Hence DataSet and DataTable are objects within the System.Data namespace and not the System.Data.SQL,etc... namespace.
In essence:
- BLL passes neutral types to the DAL (e.g.: string, int, bool, long,float, etc..)
- DAL is responsible for converting those types to database specifci types if required before passing them on to the data source
DAL returns neutral data types to the BLL (e.g.: DataSet, DataTable,etc..)
- BLL is responsible for using the content of those neutral data types to create, populate and return specifci Business Entities
Your BLL must reference your DAL. that's it.
You can off course completly ignore this model and hack about as many suggested previously using IBOOK,etc... but than your are not using the intended model and might as well throw it all into a single assembly as you won't be able to maintain it independantly anyway.

Resources