It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Can someone please explain which part of the provider model best represents the business layer?
Where should the business rules and business logic live?
If you mean something like the Membership Provider in .net, I would say the Business Layer uses the providers as a service (like John states). Though the line is a little gray if you are implementing providers yourself (like is a user a business object? if so what about the rules in the provider logic?).
Typically providers are developed separately from business applications because they are more infrastructure type code.
However, if you are just interested in the provider portion then, you typically have the following parts in a provider:
1. infrastructure stuff (config reading/database communication/etc)
2. provider interface (provides the service to consuming code)
3. 'business' objects and rules
I guess the business layer would be the implementation of the specific provider (there is usually a base class that implements the infrastructure stuff). For instance the membership provider deals with user and membership objects and has a few rules on how to do what it does as a provider.
Unless you're talking about a different "provider model" than I am, there is no relationship to a business layer.
A provider model is simply an architecture where one or more components provides a set of services. For instance, in LINQ, a LINQ Provider provides the mapping to a data store or other source of data, while the .NET Framework classes provide the rest.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have read that reflection is particularly useful when dealing with plugins. Could someone kindly highlight the benefits in this particular situation? Both in C# or Java.
"At the highest level of abstraction, the host application must be able to load plug-ins and then communicate with plug-ins to take advantage of their designed services. Both of these tasks can be implemented in different ways depending on a developer’s choice of language and platform. If the choice is C# and .NET, then reflection can be used for loading plug-ins, and interfaces or abstract classes can be used as a means for generic communication."
If you Google some of that you can see the article and read some more on it.
Why don't you just Google it?
In case of .NET you can use an interface to create a basic layout of a plugin. Let's call it 'IPlugIn'. Then you load an Assembly with a class implementing IPlugIn. Now you can look through all the types if one is derived by IPlugIn or define Attributes on the assembly to indicate which class is a plugin.
In my opinion you do not need to rely on reflection for plugin implementation. I'd suggest using usual interfaces and services. Define some interfaces for your plugins to implement and let them consume the services that will help them integrate with the framework you want to provide them.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Interface should be used when none of the implementation details are available to the current scope of the code.
Abstracts should be used when some of the implementation details are available to you.
Query - Why still these terms are required? Why can't Business objects directly communicate with DataAccess.SqlServer Layer?
Interface should be used when none of the implementation details are
available to the current scope of the code.
Not really. What you're referring to is encapsulation. There is the concept of "information expert." Only the class that knows how to do something should be the one doing it. Interfaces are used for polymorphism and decoupling. When consuming code wants to treat certain types of objects the same way, that code can use all of those objects the same way by treating them as the interface type.
Abstracts should be used when some of the implementation details are
available to you
I'm not sure what you mean here. I think you're confused because this doesn't sound right. Abstract classes are used the same way interfaces are, except that they're allowed to have implementation in them.
Query - Why still these terms are required? Why can't Business objects
directly communicate with DataAccess.SqlServer Layer?
They can, but at the cost of maintainability, flexibility, and testability. If you want to replace your data layer with another, you can't because the consuming code has a direct dependency on the current data layer. If you want to unit test your logic, you can't without hitting the DB. If you put your database classes behind an interface, you could mock the data layer in unit testing and test your logic classes without hitting the database.
Very Short Example
public Foo FooLogic
{
IFooData fooData = DataAccessFactory.GetDataClass<IFooData>();
return fooData.GetFoo();
}
Now your logic class isn't tied to a particular data class. The factory can return a real FooData implementation, or it can return a mock data object, or a new data access layer can be put in place without affecting the code in the logic class.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have an utility library with the class ConsoleApp, which has only static method like GetIntValue(string name) to ask user to enter the integer value of the parameter with specified name, or functions to parse command line parameters.
As for me ConsoleApp is an utility class, and inheriting it just to get avoid "ConsoleApp." in the code looks like BaseBeen anti-pattern.
But on the other side, ConsoleApp will be inherited only by the classes that is really Console applications, in this way, it's not a BaseBeen.
So, is it really BaseBeen?
SOLID design principles (particularly SRP, O/CP, and DIP) suggest that you're better providing that functionality via delegation (e.g. strategy pattern). Has-A is better than Is-A, etc.
However, you're pretty squarely in first-world-problems territory here because Program.cs is very much on the transient end of your codebase. Clearly you might need to parse some command line parameters before your bootstrapper runs (e.g. to configure your bootstrapper!), so you might find it challenging to inject some kind of value provider.
So, I'd say yes it's an antipattern, however there are probably more important things to worry about.
See e.g. http://s3.amazonaws.com/hanselminutes/hanselminutes_0145.pdf page 8 where Uncle Bob talks about DIP:-
"Main is the most concrete of our
functions and it will create all of our instances and all of the
factories ... and it will then
hand off to the abstract part ... and the
abstract core will manipulate it as though it were in this fantasy
world where everything was abstract."
If Main has to call some static methods, that's ok. If you want to inherit from a utility class to make it easier for you, that maybe smells a bit but I don't really care. Just make sure you know where the boundary is. If you're using your static utility class outside of Main then you're likely to have a problem.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have a large existing project in Silverlight which has many user controls with code behind files for complicated business logic. I don't know if I can still migrate my code to the MVVM pattern (I'm pretty new to this pattern). What I mean is that if it is easy to migrate the existing code or I must rewrite everything to fulfill this MVVM requirement?
Also, it seems the business application template is a type of MVVM. Is this the most popular template I should use? Is there any online tutorial to learn this template?
Many thanks,
Wei
I would rarely recommend migrating existing code to fit a new design pattern. This is really only cost effective if the project is fairly small and you're migrating in preparation for making a very large number of changes (which will then benefit from the 'improved' pattern.) Note, also, that the productivity benefits of a pattern like MVVM are somewhat delayed (there is a lot of time spent learning the pattern, so you need to be able to tolerate increased costs and delays in the short term.) If I were in your shoes, I'd practice MVVM on new projects or on reasonably well-isolated add-on features for your application. Either that or work on some personal side projects; a Frankenstein software re-architecture project is a maintenance engineer's worst nightmare.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am using simple 3 tier architecture.
In this I am using DTO classes to communicate between UI,BL and DL.
So there is any better way for communication between layers? or this is the right way?
DTO, Data transfer Object, is the concept for distribution layer, you use when transferring data between your consumers and your service. So, if you don't publish any service, get off DTO.
To answer your question, it also depends on how complex your application is. If it's simple, just use CRUD operation, or you can even use DataTable, DataSet for communication.
Otherwise, Domain Entity from DDD is the core object for communication between layers: Data Access Layer, Business Logic Layer and Presentation Layer.
Basically, there are some different type of objects in application:
DTO, use when you public services, main object to communicate between consumer and your service.
View Model, object in presentation layer to support UI.
Domain Entity is from Business logic layer to contain business logic.
Be careful with the term:
Tier: it means physical, like database server, web server.
Layer: it means logical layer: Persentation Layer, Business Logic Layer, Data Access Layer.
Read this tutorial it is very informative. It will help you to decide is DTO right for your scenario.
In addition to #Talha's answer, I'd recommend this article. It is EF-oriented, but concepts, described there, are common ones.